Tuesday, 24 January 2012

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:

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.