The strategy of architecture

A large portion of the practical side can be defined within an architecture strategy. The overlap of business and IS strategy will allow you, as the architect, to build this strategy. The architecture strategy is the plan for the development of the architecture that will support the business. Why does one need an architecture strategy? According to Forrester: "The difference between `architecture` and `architecture strategy` is critical because the evolution of architecture over time is as important to architecture success as is the design of the architecture itself."

Often the architecture process is seen as a once-off effort to be performed during analysis or design of solution sets. This type of thinking results in the standard shelfware architecture that costs companies a great deal and results in a heavy volume of information gathering dust on the shelf. It is imperative that a holistic view of architecture is developed, one which considers both current and future needs.

In the development of an architecture strategy, consideration must be given to the following domains:

* Architecture readiness, capability and maturity of the business;
* Paradigms of thought and views;
* Scope, values and principles;
* Process and methodology;
* Toolsets;
* Models and frameworks;
* Organisational issues;
* Communication;
* Implementation and use of the architecture;
* Architecture governance, including sponsorship and support; and
* Architecture enforcement and management.

Over the next couple of Industry Insights, I will be dealing with each of these in detail to help us arrive at a definition of an architecture strategy for your company.

It goes without saying that an organisation must be ready for an architectural function. There are various signs (some of which can be seen here) which can help you determine whether or not the environment is conducive to building a robust architecture strategy and implementing a defined architecture. Of key importance is the quality of inputs you can use to define architecture. Historically, companies with a low capability maturity and weak process and asset definition are difficult to develop an effective solution for.

The architecture strategy is the plan for the development of the architecture that will support the business.

Craig Martin, MD, SiloFx Enterprise Architecture Solutions

Often, a short exercise is conducted to determine the readiness of a company to perform a full architecture exercise. Issues around process, asset and people readiness would be identified as part of this assessment and would form part of an action plan. This action plan will help raise the profile of those areas that need to be improved in order to implement a successful architecture. The exercise is the process of collecting and analysing data concerning the current state of the architecture, drawing conclusions and reporting results. The overall purpose of this assessment is to determine whether the current environment is aligned or misaligned with the organisation`s needs and goals.

A readiness assessment is also a valuable input into justifying to business that a full strategy and permanent architecture function needs to be developed. The assessment can provide insight into:

* Determining how the current architecture contributes to perceived business problems and successes;

* Understanding the cost/benefits of the current architecture towards the organisation; and

* Identifying whether an architectural exercise can improve business costs and inefficiencies.

The ultimate outcome of this exercise is to provide business case inputs for the funding of a full-time architectural programme.

In planning an architecture strategy, the question is often asked: what comes first, the process model or the assets (the data)? This is a long-standing debate among the various personality types within architecture (see personality types in my previous Industry Insight). The more pertinent question, however, is which one drives out which.

Due to conflicting definitions of this type of architecture, I prefer the term asset architecture. Whether you view it as data architecture, software architecture, domain and semantic models, or entity models, the principle is the same - these all reflect assets within the business.

While there are those who believe that asset architecture is more robust and stable over time, there are others who insist that a process-centric view of the world is essential since it is human nature to think sequentially through processes.

In order to best understand this, we need to look at the ultimate goal, which is to enable and automate business processes across an enterprise. The means to do this is through resources, primarily technology and people. The processes, along with the data they manipulate, are bundled into information, ie take raw data and add context. The representative of this is an application, which uses processes to manipulate data. The application blueprint therefore carries down into the technology arena so we seek to group like processes that perform like transactions on like data, and apply technology to solve this grouping.

A process is merely a mechanism to transform an asset from one state into another. But you need to determine what that asset is in order to determine the processes that can act upon it. The only way to make that determination is to look at the business model, ie what the business does to make money. This is separate of a process model.

If all other transient dimensions (such as people, technology and causality) are removed from the determination of the business model, then this model should be fairly robust.

If, however, I build my solution from a process perspective I will eventually arrive at what is referred to as a data silo. Each department builds their own processes and then understands their data requirements from these. They then build their own data structures and buy or build products to enable them. Systems integrators then earn an enormous amount of money delivering solutions which ensure that all of the systems communicate across multiple different definitions of an asset architecture.

A more ideal solution is the creation of a process silo. This leaves the process in control of the distributed function or department where it can change multiple times. At the same time, the asset register is contained centrally or virtually, often within an eAI solution, and away from the silo approach. Thus a more data-sharing model is achieved.

One of the chief concerns in today`s architected world is the issue of multiple applications supporting the businesses across multiple units and all doing similar, if not exactly the same, work. Information is replicated across multiple disparate systems and maintained separately of the main repositories because the model did not match the requirements for that unit. One of the primary reasons the model doesn`t match is that it is developed with transient factors such as time, people and technology taken into account, and is therefore out of date the moment the first individual resigns.

An ideal solution forward is to build your process architecture and your data architecture following a goal-based approach. An interesting side effect of this approach is that the goals can reverse engineer into a process across units as well as across the enterprise. Unfortunately, this is more of an art than a science within the architecture domain.

Strawman models are developed primarily using this technique. Enterprise-level business models are broken down and the assets workshopped that co-exist with these. This Strawman model will give you the contextual data and functional elements of your first attempt at defining an enterprise architecture. The inputs and outputs of these can then be used to determine the process model.

Whatever school of thought you decide to pursue, the architecture strategy must be consistent across the enterprise. It must enforce architecture governance procedures that make the data or process paradigm a standard across all teams and thought structures within the enterprise.

SiloFX sponsors ITWeb`s enterprise architecture industry portal, which takes an in-depth look at this still often misunderstood discipline. Enterprise architecture provides the blueprint to ensure the best IT value contribution possible. It`s becoming increasingly important in a business environment characterised by mergers, acquisitions and consolidations, where the ability to quickly integrate business and IT plans is paramount.