The core challenge of any Enterprise Architecture (EA) program is getting various stakeholders on board with the proposed IT Program of works. Remember that every EA initiative is about casting change on the existing organisational landscape (primarily in context of IT).
'Change' is a necessity for every organisation. In fact, change is one of the key drivers of today's modern economies. The challenge for organisations is to understand change within and outside their organisational boundaries and plan for appropriate management. Change is generally not very well accepted across various Business Units for various reasons or there is a degree of uncertainty within IT managers whether the proposed change aligns to the business objectives.
This is where Enterprise Architecture can help, but how? By using Principles Based Approach.
Every organisation is built upon some key fundamental business values. No organisation or business can be successful if they do not have core values to live by. These values often drive core business strategies or objectives. These values are available in some form of print material in every organisation. The challenge is to understand the business values and map them into IT Principles to define appropriate IT architecture governance.
Principles are simple, direct statement of an organisation's basic belief about how the company wants to use information technology over the long term, to support their business. They are articulated philosophies about Information Technology which are translations of the main aspects of a company's business strategy into language of technology managers. This approach provides a transparent and un-ambiguous mechanism for IT Managers daily decision making; hence greatly assisting governance process.
No matter how well the organisation structure is defined, unless there are common beliefs among decision makers, there will be ambiguity in decision making process. It is imperative for CIOs to have IT Principles well defined and mapped back to business objectives as part of IT strategy so that unnecessary arguments can be diffused and IT decision making process can be fast tracked.
How to define IT Principles and map them to business objectives?
The approach to define IT principles is as follows:
- Business Imperatives: Analyse corporate strategies (assuming that they are well defined) and identify key business imperatives (Even these are in corporate strategies). The corporate strategies are the highest level of mandate across any organisation. It makes it easy if these strategies are in place and are well defined. They can directly feed into principles definition process.
- Strategic Themes: All business imperatives can be collated into core strategic themes (for ex: customer growth, operational efficiency, improved governance etc.). Strategic themes are summarised view of all business imperatives. Once we understand these themes, it is easy to understand the downward impacts on IT landscape.
- IT Impacts: Conduct
high-level IT impact analysis in terms of capability gaps. ICT may not have the capabilities in place to support strategic themes. This should lead to core IT capabilities required to support strategic themes /objectives.
- IT Principles: Once the core capability gaps are identified, it is easy to define high level IT principles by which we should work together to address these gaps. Most of the time IT principles are based on industry best practices (this is an indicator of industry maturity). Make sure that at this level we are defining principles for IT Managers, five principles are possibly too few and twenty are too many. Optimum figure would be ten to fifteen. The core idea is to have the principles on a page (Principles Cheat Sheet for managers, including the CIO) clearly showing relationship between business imperatives and IT principles.
- IT Governance: Once these high-level IT principles are defined, we can then understand the key governance gates required to mandate these principles. Key IT governing bodies like IT Council, Architecture Review board, PMO etc. are defined and mandated to implement these principles across all the major changes across IT landscape.
It is vital that these principles should appear in key IT strategy. Once they become part of IT strategy, mandating them across IT then is just a matter of managing non-conformances.
To achieve further maturity in IT decision making process, there should be low level architecture principles defined in alignment to core IT principles. These principles are mostly divided into Infrastructure and Application domains and are utilised by Solution / Technical architects across the organisation.
NOTE: The key to architecture governance is not in the definition of principles but application of them. Take key stakeholders on journey when you embark on IT principles definition process. More they believe in these principles, easier the implementation will become.
Example:
Business Imperative | IT Principles | Architecture principles |
Collaborative brand and business partnerships | Business Systems should allow information exchange encapsulating both business rules and data |
|
Let's have a look at the above statements:
- Business Imperative (Collaborative brand and business partnerships):
The above statement clearly indicates that the business is trying to expand (possibly in the same vertical or across verticals) either through buying-businesses or partnerships. Imagine the complexities it creates for the CIO. Some of the key issues he will face would be:
- How to integrate information between systems both within and outside organisation?
- How to speed deployment of new capabilities but still harvesting the existing investments?
- How to guarantee the quality of information (data) in disparate systems environment?
- How to reduce resource costs and still be able to manage expanding IT portfolio?
- And many more…
The core impact from the above business imperative is Integration (of systems and information).
Hence the following IT principle:
- Business Systems should allow information exchange encapsulating both business rules and data:
The core purpose of the above principle is to make sure that when a new capability (System/Solution/Product) is added within ICT, it is able to share the core information (data) with the other systems with minimum challenges. This will allow easy integration with business partners leading to the above defined business imperative.
Remember:
IT is trying to solve one and only one major issue for the last 10 years – INTEGRATION. Most of the industry is trying to focus too much on the integration tools and technologies, but we always forget what we are trying to integrate – THE DATA.
(I can write another Blog on this subject but later).
The Issue with integration is that the data we are trying to integrate is GARBAGE hence garbage-in garbage-out (GIGO), no matter how sophisticated integration tools are!! The 'One Customer View' cannot be achieved if we do not address the fundamental issue of 'Data Quality' (DQ). Even SOA cannot help without DQ as an integral part of solution (I know this is subject to heated discussions, but this is my view).
The morale of the story is that whenever we buy / build systems, we should make sure that they allow us to integrate with the core data without hacking at the data level (This is another major issue, we are trying to integrate data at database levels forgetting that the business rules are built in the apps not databases, hence the data quality problems.).
To support above IT principle, we need certain architectural disciplines (I am only giving example of two here):
- Design Application to reuse components: This is obvious, we cannot reuse if it not reusable!!
- Define Services with clearly defined boundaries: Applications / Systems / Products should know and manage their own data and business rules.
As you could see, I have tried to show how architecture governance applies from top to bottom level. It is quite clear from the above examples that architecture aspects within IT actually maps back to business imperatives. Once we can make various stakeholders (especially managers) understand these mappings, it is very easy to mandate architectural governance.
I hope this article helps you understand the value of Principles and their key role in managing and achieving IT Architecture Governance.
