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.
Software architects work with business leaders to design software based upon business requirements. A common problem is that our customers sometimes provide a specification of how the software should work instead of what it is supposed to accomplish. Providing a functional or technical specification limits our flexibility to do design.
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!
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:
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 rai
ls (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.
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:
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…
…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:
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:
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.
Service Virtualization for Dummies
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).
DevOps for Dummies provides an IBM point of view on DevOps.
Application Release & Deployment for Dummies addresses the strategic technologies:
