The Basis of the Requirements-Driven Business

About a month ago I started working for a new three man startup business, Advised ICT Finland Oy (site is only in Finnish, for now) which offers primarily Enterprise Architecture and Information Architecture consultancy services.

Here's the thing, though: for many Enterprise Architecture seems to be something that only Big Businesses should care about: something massive, time consuming and expensive that does not even fit to concept of agile business. True enough, it can be all this - but it does not have to be. The concept of Information Architecture seems a little confusing, too as the definition tends to vary depending on the context.

At the heart of it all things are simpler than some might think.

Identify - Specify - Satisfy
The way I see it business is always driven by requirements. To have a requirements is to have a need; if there is no need making investments and changes simply does not make any sense.

The Requirement-Driven Business thinking is based on three logical steps:

Simple Basis of the Requirements-Driven Approach

Assume that there is a company that has existed for years and business has been reasonably good. Now the management has come to realise that the world is changing and if the company intends to stay afloat in the coming years it must change along with the world.


Identify Requirements
The company has served its customers well over the years, but it is no longer enough just to have a good customer service. Customers have begun to expect more, and the company also wants to have a more direct relationship with the customers in order to improve customer loyalty and the quality of products and services the company is offering, both of which would be good for business.

The management comes up with a list of what the company needs: an online service that integrates with the company's Customer Relationship Management system, offers variety of community features and is customisable over time. In other words, the company has just identified requirements.

In other words, identifying a requirement is as simple as saying "in order for our business to be successful we need..."


Specify Requirements
To say "I need this" is easy. To explain what it actually means in practical terms i.e. to specify a requirement takes a bit more effort.

The first step was to identify requirements. The next step is to specify requirements which will transform few high-level requirements into a list of specific, detailed requirements. A good requirement has qualitative and/or quantitative aspects that can be measured in a way of determining if the requirement has been satisfied.

There are three common types of requirements.

• Business Requirements: the new online service must benefit the company's business; otherwise there is no reason to invest in it. The investment in time, money and resources must be justified (e.g. increase revenue by X per cent, increase productivity by reducing time it takes to get something done). On the other hand, business requirements must be realistic in order to have any value.


• Functional Requirements: the new online service must enable users to accomplish specific tasks in an efficient and practical manner. There are also things the service must not allow the users to do. In some cases the service itself must be able to function autonomously. If the service does not satisfy functional requirements it is about as useful a broken window during winter.


• Non-Functional Requirements: the new online service must operate and perform above specific limits. It is simply not enough to support 10 concurrent users if the service has 10 000 users with a thousand users logged in any given time. These requirements also address multitude of concerns such as reliability, maintainability, security, inter-system compatibility and so on.

Identifying Risks

Any system or operation involves risks which can be handled in one of two ways. Many choose to ignore the risks in order to save time and money in short term only to end up spending that time and money many times over when a risk inevitably becomes a reality. I recommend the opposite: spend some time and money now so that when things (again, inevitably) go wrong the fallout can be controlled.

For example, the Failure Mode and Effect Analysis (FMEA) can be used to identify potential risks and what effects realised risks might have. Risks have three metrics:

1. The likelihood that a risk becomes realised.
2. The severity of effects when a risk is realised.
3. The difficulty of detecting what has happened in time.

Each metric receives an integer value which often is between 1 and 5. By combining these three values the risk priority value is determined.

Through risk analysis an additional set of requirements can be identified and specified. Most risks can be eliminated through careful planning and implementation, and by refining operational procedures. At very least there must be ways to exercise damage control to limit the effects.

Satisfy Requirements
Once the requirements have been identified and then specified in practical terms they can be satisfied. This is to say the hands-on implementation work can be started. This is when the new online service is developed, tested and finally taken to production.

With well-defined requirements the architects, developers and testers know exactly what the new system must do and how it must perform. Well-defined requirements will also make it more likely that when the new system is taken to production it becomes a valuable tool and resource for the company instead of colossal waste of time, money and resources.

However, this is not the end but just a new beginning: as the online service is used, world changes and the company evolves over time new requirements are identified and the cycle begins anew.

The iterative requirement driven cycle.

The Requirement-Driven Business is an iterative cycle of continuously identifying, specifying and satisfying requirements through various means. This is simple in principle but there are many ways to do this in practice:


Summary
Enterprise Architecture methodologies such as TOGAF help to control the business as a whole and through this identify various requirements. Through Enterprise Architecture modelling of business management can, for example, see how everything fits together, what could be improved, and how changes in one aspect of the business would affect other aspects of the business.

Information Architects often involve themselves with requirements specification work and risk analysis, but this is only a part of their work, which also involves activities such as high-level architecture design, data modelling, service concept design, and technical team leading. There is no single definition for Information Architecture that would be independent of context, but at least I personally prefer to accept a holistic view of it.

Technical Architects such as Software Architects, Network Architects, and Database Architects along with similar specialties of developers and testers come along when the practical, technology specific implementation work begins in order to satisfy requirements and create something that can be of value. Multitude of methodologies, processes, technologies and frameworks are available at this point and admittedly it is a measure of professionalism to be able to select the ones that best serve the purpose.

Better protection against GPU brute force attack with bcrypt (and common sense)

Summary
For those of you who prefer to get to the point right-away instead of being lead to it, I have two points to make.

First, when it comes to password security it is better for common users to use longer (>8 characters long) and less cryptic passwords than shorter yet morecryptic passwords. By cryptic I mean passwords including lower and upper case characters combined with numbers and special charaters such as '#fK1~2'.

Why? Because a common users are more likely to be made vulnerable when their favourite site gets hacked during which the user database is stolen along with the usernames, passwords and the rest. At that point there will not be a single person trying to guess your password but instead a tireless GPU driven software doing a brute force attack by systematically going through all possible character combinations at speeds exceeding many hundreds of millions combinations per second: your sneaky 6-character cryptic password would be cracked within few seconds.

That is not to say the passwords should not have any special characters and numbers and the rest: there should as those make dictionary based attacks less likely to succeed. The point is that while having more characters in a password makes it stronger but overly cryptic words are harder to remember so if you have to choose between length and cryptic it is better make the password a little less cryptic and that much longer. The XKCD says it oh, so well, as usual :)


The second point is for software architects and developers who can significantly improve the security of their hashed passwords by adopting the BCRYPT hash function instead of common SHA-2 variants (and surely none of you are still using MD5 or SHA1 hash functions to encode passwords these days, right? Right?)

Why? Because bcrypt can be made very expensive to use so that it would take milliseconds (or even seconds, if you have paranoid tendencies) to encode a password instead of microseconds which is achieved by most of the common hash functions. It is trivial to spend about 0,6 seconds to encode user's password during registration and login as these operations happen reasonably rarely. However, those 600 milliseconds per single encoding becomes anything but trivial when a hacker attempts to brute force through all the passwords in your user database. As last line defences go, bcrypt should be preferred over other hash functions including SHA-2 variants.

Want to know more? Keep on reading.

The Problem
It has long been a common practice to store user passwords in a hashed form instead of the clear, human readable form. For years hash-algorithms such as MD5 and SHA-1 have been the preferred methods, but these days neither should be used for any security related purpose as they have well-known vulnerabilities. Instead many recommend that these days SHA-2 should be used, as it has no known exploitable vulnerabilities (apart from inept and lazy people who are using passwords that are too short and simple to stand against educated guess).

For those with a less technical background, a hash function is a one-way cryptographic algorithm that takes a variable length input and calculates a value that is unique for the specific set of data (e.g. file or string). It is not possible to reverse given hash value to reveal what the original value was. So when applied to passwords the way to verify if the given password matches with the hashed password in the database, the given password is hashed with the same algorithm and if the two hash values are identical it means that the right password was given and use may login.

For example, if the password is 'secret' the hash value (SHA-256) is
'2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b'

Why passwords should be stored in their hashed form? Obviously hashing does not protect against somebody  trying to log in to service by using another user's username while attempting to guess what the password might be (to protect against this the service should temporarily lock user's account after n failed login attempts). Instead hashing the passwords is the service's last line of defence when a hacker gains unauthorised access to the user database.

User databases get hacked all too often. For example, in 2011 Sega lost 1.3 million user passwords, Sony's Playstation Network got hacked at least twice after which about a million usernames and passwords were made public by the hackers, not to mention many other known cases over the past few years (and not nearly all cases are known to public).

Hackers have been quite busy indeed but the designers and developers of those services should also take a good look at the closest mirror: after all, hackers merely exploit the existing holes in various libraries and services, many of which have been publicly documented.

Cause of Problem
While hashing is a good way to protect a password against the eyes of unauthorised mortals, they can be vulnerable against brute force attacks. Modern computer components are simply so fast and efficient that brute force attacks (where each and every possible combination is tried until the right combination of characters is found) have become quite reasonable option for attackers.

A modern brute force attack utilises GPU instead of more traditional CPU. Consider this: while a CPU based password recovery tool might take about a year to crack an eight-character password, a similar GPU based password recovery tool could do the same trick in less than a day. In another words, a 13-year old with a gamer's desktop computer and simple software tool could crack a list of typical hashed passwords within hours or days, if not in minutes. Now consider for a moment about what a well-resourced and determined professionals would do to passwords in the user database of your favourite web site should they gain access to it.

For example, a dirt cheap ATI Radeon HD 5450 can handle about 52 million SHA1 or 126 million MD5 hash computations per second. Upgrade to ATI Radeon HD 5970 and you would be doing about 2 320 million SHA1 or 5 631 million MD5 calculations per second, and that is with just a single GPU. Most desktops can have two linked GPUs, including the one I have under my desk that I have dedicated just for gaming and LAN-parties.

To put things into perspective, ATI Radeon 5770 can crack a five-character password under one second while a typical CPU might be do the same in about 24 seconds or so. A six character password would take about four seconds for 5770 to crack, and a seven character password would be sorted in about 17 minutes. The respective times for a typical CPU would be around 90 minutes and four days, or so.

The Solution?
Obviously there are no guarantees but there are ways to frustrate most attackers to a point when the reward just isn't worth the trouble.

For a common user the best protection is not to use overly cryptic and hard to remember passwords with caps, numbers and special characters (e.g. #fK1~2) but simply to use longer passwords. For example, if the system is using ASCII that has 95 printable characters, each new character in the password multiplies the number of possible combinations by 95. On the other hand, if your password is just a common word then you are wide open for dictionary based attacks and guesses of people who know you. Go for the middle ground.

At the same time software architects and developers should ditch the ye olde SHA-2 variants and similar algorithms and move to BCRYPT.

Bcrypt is a Blowfish variant that has one very important aspect that sets it apart from most other hash algorithms: it can be made very expensive to use in a world where cheap equals bad. Most hash algorithms have been optimised to calculate a hash value for large sets of data as fast as possible (for example, an AMD64 CPU can calculate MD5 hash for 335 MB of data in one second) which is great when one needs to find out if two large data sets are identical, but bad when dealing with common <10 character passwords, as shown earlier.

Bcrypt on the other hand is designed to be slower instead of faster when calculating the hash thus making it easy to increase the expense of brute force attack as a single hash calculation would take milliseconds (or even seconds) instead of microseconds. Combined with properly long unobvious passwords bcrypt can seriously frustrate GPU based brute force attacks while attackers relying on CPU should not even bother.

It is important to put this into proper context: it is perfectly fine for a password hashing to take about a second during registration and login as these happen fairly rarely: a typical user registers only once and might login to service few times a day whereas a hacker would need to go through as many individual passwords in as short time as possible. Given certain amount of time the hacker will have some of the bcrypt encoded passwords cracked, but not nearly as many as he would have if the passwords had been e.g. SHA-256 encoded, whch i in turn would be less than when dealing with *gasp* MD5 encoded passwords.

Another very nice thing about bcrypt is that it can be adapted to match Moore's Law: it has a work factor that can be freely increased as computers become faster as well as to tweak the balance between performance and security. Bcrypt is available for most programming languages and for example the Grails Spring Security Core -plugin by Burt Beckwith makes the using of bcrypt practially trivial.


Hopefully in the future I will not be seeing web sites that limit user passwords to max 8 characters while enforcing ridiculous character inclusions while at the same time I do hope to see frustrated hackers pissing their lives away by trying to brute force through bcrypt encoded passwords. It would be a nice start, but only a start as far as improving software security is concerned.

Of Information Architects and Business Architectures

Information Architects are somewhat a rare breed: there are not too many of us around, at least when compared to the number of other types of IT architects.

The term Information Architect was first coined by Richard Saul Wurman (as quoted in Wikipedia's article Information Architecture):

Wurman sees architecture as "used in the words architect of foreign policy. I mean architect as in the creating of systemic, structural, and orderly principles to make something work - the thoughtful making of either artifact, or idea, or policy that informs because it is clear".

Although it safe say that the meaning of the term has evolved since then, and today the way it is understood seems to vary depending on to which branch of IT it is being applied to. That being said this is how I see and understand my role and position as an Information Architect.

On a very basic level IT architects can be divided to three high-level categories: Business Architects, Information Architects and Technology Architects. Although some might argue that Business Architects don't have all that much to do with IT, these three groups depend on each other in the sense that Business Architects begin by laying the foundations for sound business operations by defining the Business Architecture, which also provides a stepping stone for the work of Information Architects that in turn provides a high-level solution design which will be implemented by various types of Technology Architects.

Briefly about Business Architecture
Object Management Group's Business Architecture Special Interest Group (BASIG) defines Business Architecture as follows:

A blueprint of the enterprise that provides a common understanding of the organisation and is used to align strategic objectives and tactical demands.

 BASIG further explains it in the Business Architecture Overview:

Business Architecture defines the structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the ever-changing market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives. 

Business Architecture primarily focuses on the business motivations, business operations and business analysis frameworks and related networks that link these aspects of the enterprise together. 

 The key views of the business architecture are the

1. Business Strategy view: the tactical and strategic goals the organisation strives to realise.
2. Business Capabilities view: the primary business functions that define what exactly the organisation can do and how.
3. Value Stream view: the set of end-to-end activities that delivers value to all stakeholders.
4. Business Knowledge view: describes the shared semantics within an organisations and how they are related to each other.
5. Organisational view: relationships among roles, capabilities and business units.

Obviously there is more to all of this but suffice to say that a well-defined Business Architecture form one corner-stone of potentially successful business. This is also an important foundation for Information Architect's work.

The role and position of Information Architect
Information Architects stand between Business Architects and Technology Architects, yet the division is not entirely exclusive but instead Information Architects benefit from having understanding across all three domains. For example, Information Architects need to be able to understand and define business processes at least as far as those processes need to be supported by IT services. On the technology side Information Architects should have practical experience from software development and of various IT systems when coming up with possible (high-level) solutions for a organisation's needs.

So it can be said that the Information Architecture begins with business processes and rules, and leads to practical technical implementation, but between these two there is much that falls to the domain of information architecture. Most notably the requirements specifications, which are mainly mapped through discussions with various stakeholders (once they have been identified):

• Business Requirements: these requirements describe how the system must benefit and support the organisation. In most cases business requirements include relevant business processes that the system must support, and various quantifiable (if at all possible) goals such as increase in income, decrease in expenses, more new customers, being able to perform certain tasks in less time than before and so on.
  
  The investment in time, money and resources are justified once the business requirements are fulfilled in production.
  
  
• Functional Requirements: these requirements define what users must be able to do (or not do) and accomplish when using the system. Most commonly functional requirements are described by writing Use Cases along with actor descriptions. In addition functional requirements may include descriptions of algorithms, methods and models for data processing, and other essential details that relate to the way users are going to use the system.
  
  
• Non-functional Requirements: these requirements define the quantifiable, qualitative metrics that are used to measure the system's performance. The possible metrics range from "x operation in y units of time" to high-availability demands (e.g. 99.95% uptime) to various compatibility, testability, robustness and many other requirements - just remember that each metric needs to be monitored so too many is almost as bad a not enough. The key is to identify those metrics that have most impact on how business requirements are being fulfilled.

Requirement specifications are just one part of the Information Architect's domain. Everything Information Architect does is to increase knowledge and understanding of what the organisation's needs are and what is required from a system that is supposed to meet those needs. So in addition Information Architects often involve themselves with activities such as risk analysis (I personally prefer to use Failure Mode and Effects Analysis), workshops and background research.

Finally after information has been gathered and analysed, and the problem domain is properly understood Information Architect can put it all together and come up with a solution proposal, which often includes a high-level logical architecture modelled in UML. Initially there might be several alternative solution models but if the information gathering and analysis has been done properly and the underlying business architecture is well understood eventually one solution model will rise above all else.

What is usually left outside Information Architect's domain are the details of technical implementation such as the programming language, server environments, tools and the finer points of coding. That is not to say that the same person can't also handle the role of a Technical Architect, such as Software Architect, Database Architect, System Architect or some other specialty.

In addition to everything else Information Architect must have good writing skills and be able to produce clear, systematic and concise documentation; get along with and understand the views of both business people and technical peope; balance conflicting needs of various stakeholders, or at very least be able to reach reasonable compromises if conflicts cannot be resolved altogether.

Oh, and have a lots of patience and good sense of humour. It definitely helps.

A little bit about Nokia's fall and more about Clayton Christensen's The Innovator's Dilemma

Clayton M. Christensen wrote a book over ten years ago, The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail. I first read it in 2004 as part of my studies in the Tampere Polytechnic University. Following the news about Nokia's demise I felt like reading it again.

The question Clayton Christensen presented is at the very core of any business: how come companies that were at the very top of their game eventually failed. These are the companies that dominated their markets and were hailed for their good management and yet, somehow, eventually dropped the ball in a very profound way. This very much reminds me of Nokia these days: Nokia used to be leading innovator with mobile phones, utterly dominated the markets, made billions and yet, Nokia is now in a desperate struggle against Apple and Google and is probably going to sack thousands following the co-operation deal with a former enemy, Microsoft.

A story I've heard few times (don't know how true this is) tells that Nokia had a working touch screen mobile phone some seven or eight years ago, but the back-then management did not think it had any call in the markets. Oops. Around 2004 - about three years before first iPhone - Nokia published 7710 multimedia phone with a colour LCD touch screen, but because it did not become an instant commercial success it was quickly discontinued and all the time and resources spent on the development of the technology was essentially scrapped ... until Apple came along and proved Nokia wrong.

Consider reading the following article by Mikko-Pekka Heikkinen: http://www.howardforums.com/showthread.php/1679550-Knock-Knock-Nokia-s-Heavy-Fall...

But back to Christensen's Innovator's Dilemma.

Why market leader companies almost invariably fail when markets change? How come a company that had a finger so well placed on the market's commercial pulse at one time so easily flatlines in the next generation market? Christensen writes that

Precisely because these firms listened to their customers, invested aggressively in new technologies that would provide their customers more and better products of the sort they wanted, and because they carefully studied market trends and systematically allocated investment capital to innovations that promised the best returns, they lost their positions of leadership.

Now that should give most managers a pause. They are doing things exactly right and then, somehow, it turned out to be the completely wrong thing? Well, yes and no. No, because they in fact did do the right things at the given time and situation and yet, yes because they failed to understand that their status quo would not be permanent. The decisions they did while everything was going so well prevented them to come up with the next good thing.

Christensen talks about sustaining technologies and disruptive technologies. The former is essentially about improved performance of established products that the current mainstream customers value. For example, ever faster CPUs or 3,5" hard-drives with more and more storage capacity: the underlying technology is the same, it just gets more efficient and often eventually exceeds what the customers actually want and need.

The latter, disruptive technologies when they emerge typically offer worse product performance when compared against products in the mainstream markets so why invest time and resources required by development? Because of this: disruptive technologies are not based on the same value proposition as the mainstream technology but instead brings forth a completely different value proposition. Initially disruptive technologies tend to be valued by few fringe customers and products based on disruptive technology are often cheaper, simpler, smaller but more importantly, more convenient to use, as Christensen puts it.

However, what is often overlooked is the fact that once technology is establised the iterations of sustaining technologies quickly catches up and then exceeds what the markets and customers really need. Therefore a disruptive technology that is underperforming today when compared to mainstream technology, is likely to be performance-competitive in the same market tomorrow. For example, consider disk-based hard-drives and solid-state hard-drives few years ago and again today.

Take a moment to think about the following quote from Christensen:

[The] conclusion by established companies that investing aggressively in disruptive technologies is not a rational financial decision for them to make, has three bases. First, disruptive products are simpler and cheaper; they generally promise lower margins, not greater profits. Second, disruptive technologies typically are first commercialized in emerging or insignificant markets. And third, leading firms' most profitable customers generally don't want, and indeed initially can't use, products based on disruptive technologies. By and large, a disruptive technology is initially embraced by the least profitable customers in the market. Hence, most companies with a practiced discipline of listening to their best customers and identifying new products that promise greater profitability and growth are rarely able to build a case for investing in disruptive technologies until it is too late.

In his book Christensen presents the five laws or principles of disruptive technology stating that "if managers can understand and harness these forces, rather than fight them, they can in fact succeed spectacularly when confronted with disruptive technological change". There are no simple answers, mind you, but rather the important thing is to to attempt to understand the underlying point.

Principle #1: Companies Depend on Customers and Investors for Resources
In short, managers in successful companies tend to think that they control the flow of resources in their organisations, but by doing so they often seem to forget that those resources come from their customers and investors and if the company does not produce what the customers and investors want, they will take their money elsewhere. Christensen says it well:

The highest-performing companies, in fact, are those that are best at this, that is, they have well-developed systems for killing ideas that their customer's don't want. As a result, these companies find it very difficult to invest adequate resources in disruptive technologies - lower-margin opportunities that their customers don't want - until their customers want them. And by then it is too late.

Christensen points out that this makes certain sense as companies whose cost structures have been tailored for competing in high-end markets cannot be profitable in low-end markets as well. One possible solution? Creation of an independent organisation that can become profitable with the lower margins of disruptive technology's emergent market. This way the company can establish a beachhead in the new market while still reaping rewards from the mainstream market.

Principle #2: Small Markets Don't Solve the Growth Needs of Large Companies
Disruptive technologies usually enable new markets to emerge instead of offering better solutions for current markets. It will take time for the new markets to mature and once they have matured they tend to provide products and services that better suite the needs of the customers in the old market. At that point it is already too late for the big companies of the old market to transition to the new market and expect to maintain their market shares. In fact, they are lucky to even survive.

Why then the big companies fail to catch up with a new technology wave? After all, many of them initially started as a small company looking for their fortune in a new market. Much of this follows from the companies way of measuring success through growth: while a $40 million company can achieve 20% annual growth by coming up with $8 million worth of revenue growth, a $4 billion company would require $800 million to achieve annual growth of 20%. Because no new market can provide this it seems to follow that the bigger the company is the more difficult it becomes to see new growth potential in emerging markets.

Personally, I think big companies should see new markets as long term investment opportunities but this comes with risks that some managers just don't want to take. After all, waiting and seeing is so much more safer. I also think that Google has figured this out as it is constantly finding new growth from new markets; however, nothing lasts forever so it is likely that Google's continuing growth already contains the seeds of its eventual downfall.

Principle #3: Markets that Don't Exist Can't Be Analyzed
Probably all business schools are teaching that a proper market research and good planning based on known market attributes followed by timely and determined execution is the road to success. Christensen agrees that this is indeed how things should work - when dealing with sustaining technologies. 

The problem with disruptive technologies is that their markets are only now emerging. They don't really exist and therefore cannot be evaluated in the same way as existing markets are.

Companies whose investment processes demand quantification of market sizes and financial returns before they can enter a market get paralyzed or make serious mistakes when faced with disruptive technologies. They demand market data when none exists and make judgements based upon financial projections when neither revenues or costs can, in fact, be known. Using planning and marketing techniques that were developed to manage sustaining technologies in the very different context of disruptive ones is an exercise in flapping wings.

So a different approach is called upon. Christensen proposes a discovery-based planning which suggests that forecasts are assumed to be wrong rather than right and as such the strategies based on those forecasts are likely to be wrong as well. Instead managers should "develop plans for learning what needs to be known" as a more flexible and realistic approach to mastering disruptive technologies.

Principle #4: An Organization's Capabilities Defines Its Disabilities
Organisations are comprised of people that work in them and yet, Christensen points out that organisations have capabilities that exist independently of the people. First, there are processes as in ways of working and producing things of value. Second, there are organisation's values (which in my experience are not always the same as the ones found in PR-materials) that the organisation's managers and employees use to decide how work should be prioritised.

While people who work in the organisation can be very flexible, the processes and values usually are not. To certain extend this makes sense since a process is usually a practical result of trial and error and embody many best practices that lead to effective work. However, this is true only within certain context: Christensen points out that a process that is effective at managing the design of a minicomputer would be ineffective at managing the design of a desktop personal computer. Similarly, says Christensen, values that cause employees to prioritise projects to develop high-margin products, cannot simultaneously accord priority to low-margin products.

The very processes and values that constitute an organization's capabilities in one context, define its disabilities in another context.

Principle #5: Technology Supply May Not Equal Market Demand

Disruptive technologies, though initially can only be used in small markets remote from the mainstream, are disruptive because they subsequently can become fully performance-competitive within the mainstream market against established products.

This usually happens at a point when both the old and the new technology has exceeded in performance and capabilities what the customers actually need, so they begin to make their purchase decisions based on other values: "the basis of product choice often evolves from functionality to reliability, then to convenience, and, ultimately, to price".

The point is that market leaders tend to keep improving their products over many iterations of sustaining technologies believing that their superior products will keep competition behind them. While doing this they fail to notice that they have over-shot their original customer needs which can have an unexpected consequence in that "they create a vacuum at lower price points into which competitors employing disruptive technologies can enter".

Only those companies that carefully measure trends in how their mainstream customers use their products can catch the points at which the basis of competition will change in the markets they serve.

This was just a short introduction to Clayton M. Christensen's book so I recommend that you read it, if you found the topic interesting. The observations and lessons covered in this book are technology and market independent so in our quest to come up with the next Nokia (or preferabbly several smaller ones) there is much we can learn from it.

Thoughts about Data and Information

Question: What is information?

The way I see it, information is data relevant to a given context. In other words, if data can provide an answer to a question, it is information; otherwise it has very little practical value.

Consider an online service that is quietly collecting data about network traffic and user behaviour. Having oodles of data in log files or in database does little good on its own. It is only after someone begins to ask context specific questions that the data begins to acquire practical value by virtue of providing answers.

From this follows that logging and other methods of gathering data may turn out to be waste of time and resources (which often equals to money) if there do not attempt to provide answers to questions. In other words, when designing a service one should also be mindful about e.g. what is being logged and why.

I've seen too many systems that have their logs disabled in production because of the amount of data they collect every day: constant writing in a log file consumes limited disk space and even slows down the overall service performance. So when something goes wrong in the production there are no records because logs are only used by developers and testers to debug the system before going live. And even when logs are enabled in production it often turns out that the data that might be relevant is not being logged at all.

So before implementing data gathering of any kind, someone should think about what questions are most likely being asked when the service is in production and then consider what data would be relevant within that context.

Thoughts about Writing Use Cases and User Stories

Every now and then people ask me about how to write use cases, preferrably ones that are usefull. I admit this is giving me fixed feelings: I'm happy to help and I'm pleased that people still find value in these, but at the same time I find myself feeling annoyed and disappointed about how rarely projects utilise Use Cases these days.

Before agile processes became the hype they are today Use Cases were the bread and butter of any new development project that (when done properly) allowed architects to think things through few times while writing them, explained to the developers what was needed and how things should happen as well as gave the testers a solid base to begin writing their Test Cases. After all, from a good Use Case several Test Cases could be derived starting from the Happy Day -test scenario.

But I digress.

A Use Case describes a single operation performed by the end-user, such as New User Registration, User Login or Search by Using Key Word(s) without addressing techical implementation details in any way. In other words, a Use Cases explain who uses the system in question, what they can do with it under which circumstances.

When writing Use Cases one should usually imagine another user operating the system through specific user interface. There are several questions that need answering: what is the user trying to accomplish? What information the system needs in order to help the user? What individual steps user needs to perform in order to reach the goal? Does the Use Case include interaction between the user and the system? How to keep things simple and intuitive?

Basic Use Case Structure
When I'm writing Use Cases I typically utilise following basic structure. While various books and processes introduce Use Cases with quite a few more fields than what I have listed below, my experience has shown that these are the ones most commonly needed.

UC FIELD	DESCRIPTION
ID	A unique identifier for the given Use Case. [group id] - [use case number] For example, ProjectAwesome-42 or UC-001. A good notation provides identifiers that are unique, clear and informative within the given project context. Note: A common mistake is to refer to a use case by its title, document chapter or even document page number. All these are likely to change during writing and editing which would then propagate to all those other documents that reference the Use Case.
Name / Title	The name of the Use Case. For example, Create User, or Request New Password. Note: A good name typically follows verb-noun format (do someting). Keep it simple, keep it clear.
Summary	Short verbal description explaining what this Use Case is about. Few sentences are usually enough. For example, The user creates a new user account by submitting the registration form containing required and possibly additional optional personal information.
Priority	Describes how important this Use Case is considering the overall usability of the system. During the early stages of the planning a priority hierarchy of three levels is usually enough: (1) Essential: The system will not be production ready before this UC has been implemented. A core Use Case. (3) Normal: This UC is needed and once implemented will greatly improve the overall usability of the system, but it can wait until the essential Use Cases have been implemented first (it is likely that this UC cannot be implemented before some essential UC). (5) Nice-to-Have: While this UC could be beneficial for the end-users and improve the overall system, it is not strictly speaking required. Can be implemented should there be time and resources. At later stages the priority hierarchy can be expanded to include five levels especially if there are large number of Use Cases with the same priority (and there often is). It also helps to highlight which Use Cases enable the development of other Use Cases.
Actor(s)	Actor is an end-user archetype, or a role that can utilise this specific Use Case. For example, Anonymous, Customer, Admistrator, Secretary Or Client Service. Each Use Case can have one, two or several actors. It is also good to keep in mind that end-user roles can evolve over time: one and the same user could begin as an Anonymous user when she enters the Create User UC; after successful registration the end-user might become a common Secretary user until she is given the Administrator privileges after which she might retain both Secretary and Administrator roles. Note: It would be a topic for another discussion to consider whether Administrator should automatically include Secretary privileges or should they be kept separate at all times. After all, is the Administrator suppose to also do what Secretary does or should the concerns be kept separate at role levels? My opinion usually is to separate the concerns and enable the assignment of multiple roles when needed.
Preconditions	What must have happened before this Use Case can be accessed? For example, User has logged in or Account has money. Often a Use Case can be a precondition for another Use Case, such as the requirement that the user has logged in. When this is the case use Use Case ID and Name as precondition reference (e.g. UC-003 Login User). Another common situation is where certain property value(s) act as precondition. For example, UC Withdraw Money cannot happen if the user's account has no money.
Steps	What the Use Case is actually about is explained here step by step. For example, Start: Actor enters Login screen. Step 1: Actor provides username and password to appropriate form fields. Final Step: Actor clicks Login button.
Post-conditions	Post-conditions list key changes in the system after the Use Case has been completed. For example, after successful login the post-condition could be User has logged in and can access privileged services. Or if money has been withdrawn from a user account the post-condition could be the updated account balance and closed transaction.
Exceptions	Where as Steps essentially explain the Happy Day -scenario (e.g. when everything goes as typically expected) there are usually various foreseen exceptions. Most common example is a failed field validation. For example, Login might have following exceptions: E-1: Incorrect username: The Actor is taken back to the login screen and an error message is shown: "Incorrect username and/or password". E-2: Incorrect password: The Actor is taken back to the login screen and an error message is shown: "Incorrect username and/or password". E-3: Account locked: The Actor is taken back to the login screen and an error message is shown: "Unable to login: user account has been locked. Please contact customer service for support."
Comments	As Use Cases tend to go through multiple revisions it is often useful to have a place for comments and suggestions.

A bare-bones Use Case might do without pre- and post-conditions and priority, but eventually somebody has to figure these out before the Use Case can be implemented.

Use Case Iterations
Use Cases typically evolve through multiple iterations. Consider following:

First version: Once a need for a UC has been identified create the basic structure with just ID and Name.

Second version: Think about who needs this use case and what actually should happen on a high level. This defines Actor(s) and Summary.

Third version: Dive into details and think step-by-step what information the system needs and through which actions the end-user should provide that information. Each step might have 0..n (zero to many) exceptions so which ones can you identify at this point? More can be added in following iterations.

Fourth version: After most of the system's use cases has been identified are there some obvious Use Cases or property values that would act as preconditions to other Use Cases? Often one comes up with a precondition only to realise that it is actually a new Use Case.

Fifth version: Through discussions with various stakeholders and reviews Use Case begins to shape into its final form, but there are likely to be some more changes along the road...

Use Cases vs. User Stories
Use Cases are similar to User Stories often used in Agile processes such as Scrum. The main difference is that User Stories tend to be high level prose where as Use Cases are more structured and detailed.

Consider following example describing a user login.

USER STORY: Anonymous User Logs In
Description: The user opens the login page where he must provide valid USERNAME and PASSWORD combination. The basic form validation checks that the USERNAME exists, PASSWORD matches the one in the database and that the account is active. After successfull login user can access all functionalities according to his role privileges.

How to demo: First try to access some functionality that requires user to login. This should fail and user is automatically taken to login page. 

Next try login with incorrect username and/or password. The login page reloads and shows appropriate error message.

Finally login with valid credentials and after successful login attempt to access the same functionality as before login. This time functionality can be accessed.

USE CASE: Anonymous User Logs In

ID	UC-02
Name / Title	User Login
Summary	User provides required login credentials in order to gain system access.
Priority	Essential
Actor(s)	Anonymous
Preconditions	n/a
Steps	Start: Actor enters Login screen. Step 1: Actor provides username and password to appropriate form fields. Final Step: Actor clicks Login button.
Post-conditions	User has logged in and can access privileged services.
Exceptions	E-1: Incorrect username: The Actor is taken back to the login screen and an error message is shown: "Incorrect username and/or password". E-2: Incorrect password: The Actor is taken back to the login screen and an error message is shown: "Incorrect username and/or password". E-3: Account locked: The Actor is taken back to the login screen and an error message is shown: "Unable to login: user account has been locked. Please contact customer service for support."
Comments	n/a