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.