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.

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.

The Customer, the Team and the Company

I was once told that for a consultant the company must always come first, no matter what. I disagreed.

When I'm working in a customer project my priorities are clear: first comes the customer, next my team and then the company. These three are not mutually exclusive, in fact it is just the opposite: these three can, and indeed must be inclusive. It's a triangle of a mutual interaction.

Please stand-by for the obvious.

The customer must come first because without the customer there is no project. The custome is the one who controls the project funding and most importantly the project's core purpose is to benefit the customer. The consultant must look after and protect the customer's interests: the consultant must earn the customer's trust and respect since simply being cheap/expensive expert on the field is not enough to establish a good working relationship.

Always do right by your customer; the "used cars salesman" attitude ~ i.e. bleed the customer dry by making them to pay premium for everything whenever possible while trying to maximise the company profits by using cheapest available people and resources ~ should in my opinion be avoided, but then again I'm not a business/sales manager. Idealistic thinking or not, but I believe that a mutual win-win arrangement over a longer time peried tends to benefit all parties more than the instant gratification like the one that came from killing the goose that laid golden eggs.

Take care of the team because their practical work effort directly determines whether or not the project is ultimately a succesful one. If the team members are overworked, burned out, pissed off, unmotived, untrained and/or under-appreciated it will show in so many ways: their overall morale and attitude towards the customer, each other and other members of the company, the quality and pace of their work, ability to deal with unexpected change and hardship, ability to solve problems, willingness to support team mates, and generally speaking their mental ability to take pride in the results of their work, just to mention few.

On the other hand, a well-motivated team with a good morale and up-to-date training that knows the value of their work, that isn't crumbling under unreasonable workload, that are in control of their own work, and that are all-and-all happy to come to work in most mornings, can really get the job done and do it well. Personally, given a choice I would take a small team of motivated professionals over a larger team of tired techies on any given day.

What about the company, then? A simple if not simplistic logic suggests that a happy customer and a happy team should make a happy company: team has work, company gets paid and customer gets money's worth, which tends to place the company and the team high on the customer's short list the next time customer needs to get a job done. This is not say that the company's role ~ including all the other people directly or indirectly involved with the various phases of the project ~ as a mediator and an enabler isn't vitally important for the outcome of the project.


The point of all this? I don't know... that a business could benefit from a touch of ethics and humanity over selfish shareholder greed? That mutually beneficial long term business relationships are preferrable over short-term rip-offs, low quality work and use-and-toss-away approach to employee management? Or perhaps it is that in the end we are all just people trying to work together instead of resources waiting to be exploited? Might be all of the above, or it could just be some wistful rambling of an idealist.

The flip side? Of course it has to be said that not everything depends on how the team and company performs during a customer project as the customer has a key role to play too. While the company would like to maximise the profits, the customer would like to minimise the expenses, which is all perfectly understandable and part of good business. However, this often leads to a situation where the budget is unreasonably tight allowing not enough time, people nor resources to get the job done right. Sometimes customers hire consultants because they think they need their expert knowledge and then choose to ignore the given expert advice with predictable consequances. It is an unthankful moment to be a consultant saying to the customer "I told you so".

No project is a one-way street; a project success depends on co-operation and mutual respect of all involved parties (a healthy dose of common sense and willingnes to compromise often helps, too) among other things.