Web Analytics solutions help improve Web sites by analyzing real time information or information gathered from Web server logs to uncover usage patterns.

Simple, free Web analytics solutions are popular such as Google Analytics.

IBM CoreMetrics is a popular paid Web Analytics solution.  Others include Adobe SiteCatalyst, WebTrends and ClickTrends.

A good way to avoid this is to start the design process by asking about why the software is being created.  What are the major objectives?  These are the critical success factors.

Designing software is similar to designing other things and I find that, to see software design concepts more clearly, it helps to get out of the software space and free our minds from the software mindset and software-speak that has settled around our minds like a fence.

So let’s design a fence!

DISCLAIMER:  I know very little about fences, cows or deer.  The story is only meant to illustrate the concepts of critical success factors, business capabilities, projects, and maturity models.

Why?  Who needs the fence?  Answer:  A rancher.

Why does he want a fence?  Answer:  To keep his cows on his field.

Wait…the rancher has though of another reason he needs a fence…he wants to keep deer off of his field.

When does he need it?  Answer:  He needs to expand his field as soon as possible.  This only involves adult cattle at this point.  At most, this needs to be completed in 2 months.  He expects to have calves starting in the spring — about 3 months from now.  He needs to keep deer off his field during the winter — starting in about 6 months from now.

So let us summarize the critical success factors as required business capabilities:

1. In 2 months:  Ability to fence in adult cattle
2. In 3 months:  Ability to fence in calves
3. In 6 months:  Ability to fence out deer.

Now we are ready to design the technical solution (the fence)!

What does it take to keep a cow on a field?  Answer:  It depends.  For an adult cow it takes a single rail about 3 feet off the ground.  For a calf it takes a rail about 1.5 feet off the ground.

What does it take to keep a deer off his field?  Answer:  This requires the other two rails (1.5 and 3 feet from the ground) AND a third rail about 4.5 feet high.  The latter is required to keep the deer from jumping the fence.

There are technical requirements.   Unfortunately, the three rails mentioned above will not just hang there on their own.  They require vertical posts to hold them in place (infrastructure).

Now the fence is designed and we are ready to plan the work.  We will deliver the new required business capabilities (enabled by the fence) in 3 projects aligned with the 3 critical success factors and the key constraint that we must have the posts in place before we can hang any rails.

In more complex initiatives there would be dozens of critical success factors, even more required business capabilities, with a web of inter-dependencies.   But it is not generally necessary to have dozens of projects.  It should be possible to group the required business capabilities in 3-5 groups and still satisfy all of the inter-dependencies.

For recurring industry problems consultants frequently generalize these 3-5 projects in the form of a maturity model.  I will explain how/why to create a maturity model in a future post.

Perhaps yes.

We all dutifully endure the user ID and password on the hope that it will preserve our privacy, money and identity. As we need more and more user IDs and passwords we begin to reuse them and write them down, making them easier for friends, hackers or fellow train passengers to find. Also, snooping software such as key loggers can read them as we type them in or as they are transmitted.

Thus the need for stronger ways of identifying and proving who we are, something us techies call authentication. The fact that we are using software on our own phone, laptop or other device is a proven way to make it more difficult for others to use our user ID and password, so apps store information on the phone that it can read later to prove that you are using the same device . An even more powerful (and complementary) technique is the single-use password, where a password is generated that only works once, rendering it useless to anyone finding, guessing or snooping it.

Strong (customer) authentication is defined by the European Central Bank (ECB) as:

“a procedure based on the use of two or more of the following elements– categorized as knowledge, ownership and inherence:

(i) something only the user knows, e.g. static password, code, personal identification number;

(ii) something only the user possesses, e.g.token, smart card, mobile phone;

(iii) something the user is, e.g. biometric characteristic, such as a fingerprint.

In addition, the elements selected must be mutually independent, i.e. the breach of one does not compromise the other(s). At least one of the elements should be non-reusable and non-replicable (except for inherence), and not capable of being surreptitiously stolen via the Internet.  The strong authentication procedure should be designed in such a way as to protect the confidentiality of the authentication data.”

“Strong authentication” is generally accepted to mean a type of multifactor authentication (MFA).  MFA is required or strongly recommended by:

• European Central Bank (ECB) as specified above
• Federal Financial Institutions Examination Council (FFIEC) in the US
• Regulations in MEA such as those issued by Banking Regulation and
  Supervision Agency (BDDK) in Turkey and others in UAE and Qatar
• Monetary Authority in Singapore (MAS) in its Technology Risk
  Management Guidelines.

Most mobile apps have a user ID and password.  The user ID is used for identification and sometimes may be stored so that the user doesn’t need to enter it.  The password (or a shorter pass-code) is the first factor of authentication and represents something that the user knows.  Both are things that the user knows.

To meet the above ECB requirement a mobile app could also validate the mobile device (something the user has) and use the device as a token to produce a one-time password (OTP).

For example, Monitise/Pozitron SoftKEY uses a value stored on the device to generate a OTP to provide strong authentication that complies with the ECB definition.

I talk a lot about technology strategy and the importance of technology strategy to business strategy.  I think it is important to understand the importance of technology historically in order to grasp what is actually at stake here.  For that, best to go back to ancient times and look at what effect past technological advances have had on people.

Let me just cut to the chase.  The primary purpose of technology to business is to exploit it to gain competitive advantage.  The main point of competitive advantage is to use it against your competitors.  Extreme cases of advantage generally are used to wage war against ones competitors.  War is not the same as competition.  Competition is natural as all plants and animals compete.  This is the basis for evolution (or creation if you prefer).  War, a uniquely human activity–and specifically unique to man after the advent of technology, means to annihilate ones competition completely as much as possible.

This means that you need to think beyond basic competitive advantage.  Does a new technology give your competitors sufficient advantage to wage war?  Think about…

• the capability to manipulate oil prices being used to wage an economic war against a nation,
• the capability to manipulate local or national elections being used to wage a political or economic war against a class,
• the ability to attack networks and computers being used to wage an electronic war against an organization or group

…but content for another post because I am wandering well beyond the scope of the book now.

A notable instance of this is the ferocity with which agricultural and post-agricultural peoples have murdered hunter/gatherer, herdsmen and other pre-agricultural peoples for thousands of years.  Consult Wikipedia on this if you like which, at the time of my reading it, included: “Modern scholars typically view the stories of Adam and Eve and Cain and Abel to be about the development of civilization during the age of agriculture; not the beginnings of man, but when people first learned agriculture, replacing the ways of the hunter-gatherer.”

An easy and inspiring read about this can be found in Ishmael, An adventure of the Mind and Spirit:

A common question that I have helped banks struggle with over the years is “build vs. buy”.  For digital banking channels, banks are wondering if they should build a bespoke banking multi/omni/channel offing or buy a packaged product/platform.

The arguments for both sides are compelling:

• Building a bespoke solution offers the hope of creating a sustainable competitive advantage through a leading software development capability and innovative user experiences that are difficult for competitors to rapidly duplicate.
• Acquiring a packaged product (or leveraging a platform) allows the bank to benefit from a product road-map and offers the hope of a minimal cost market-parity guarantee.  Minimal cost because product vendors amortize the cost of developing new features over many banks.  All the bank must do is install new versions of the product.

The former is important for differentiating and the latter is important for reducing the cost of maintaining “hygiene factor” features that keep competitors from poaching customers with better channels.

The largest banks can afford to build commodity features themselves although this is in theory a waste of money.  I say “in theory” because it can be tricky to build bespoke differentiating features AND acquire commodity features from a vendor.  This ability must be engineered into the channels architecture somehow.  You need to be able to do one or both of the following:

• Plug vendor features into a bespoke solution (plug-able components).  The development of which can be facilitated by industry standards and platforms.
• Plug bespoke features into a vendor solution or platform (extension points).  The development of which are facilitated by the vendor solution/platform’s extensible architecture.

Complicating the digital channels architecture further is the notion of infrastructure.  See my series on strategic technologies.  This is generally a “buy” no-brainer.  No banks should be building their own infrastructure unless they have spotted a technology white space and a way to create a competitive advantage by filling it. Vendors are watching for this, I warn.  At least I am.  I see this as an opportunity to build a new product to sell or platform to run in the cloud.  You see banks attempting to manage this to their advantage by incubating start-ups.  The idea is to get to market first with something that is differentiating, maximize the duration of competitive advantage, and then spin it off once it becomes a commodity to spread the cost of maintaining the technology and keeping its features at market parity.

This is an area of interest for me and you can imagine that I have a lot more to say about it, which is why I am starting this series.

A great place to start to learn about Service Virtualization technologies such as GreenHat.

Service Virtualization encompasses a strategy and tool set for stubbing out components that provide services required to run a component under test.  An example service virtualization tool is IBM’s Rational Test Virtualization Server (formerly GreenHat).

• Application Deployment Automation solutions
• Release Coordination solutions.