By donflinn | December 12, 2009
This issue will discuss how an IT Architecture can encourage good IT governance and conversely how good governance can result in a good architecture. One approach to understanding this relationship is examining how various specification bodies define and recommend the construction of a good architecture and relate this to the role of good governance and vise-a-versa.
IT specifications contain well thought out paths to a good architecture, so we will be using some of the best specifications as groundwork for describing the IT Governance / Architecture mutual influence. IT seems to have a specification for everything. An IT engineer was asked if he would jump off a cliff if ordered to by his boss. The engineer’s answer – Only if there was a specification on how to jump 
We will also discuss who should comprise the committees that should be responsible for deciding the direction for IT architecture as well as what groups should be responsible for providing input to the decision committees.
Even though IT architectural governance is a more technical subject, we encourage those of you with a business orientation to hang in there as we will approach this subject from a business perspective and use a minimum of technical terms. As we discuss the governance – architecture relationship, tangible steps for implementing IT governance will emerge.
Similar to our previous discussions, IT architecture exists within its own broader category, in this case, Enterprise Architecture (EA) which, in turn, has a relationship to corporate governance. Consequently, we’ll incorporate a quick look at enterprise architecture. Over the last decade a lot of work has been done defining and putting EA into practice and companies that have made the effort have reaped substantial rewards.
Believe it or not a good definition of Enterprise Architecture is found at the US Office of Management and Budget. There has been quite a bit of top notch work put into directing and controlling that vast, sprawling enterprise called the US Government. This has been carried out by a number of highly rated people and companies, many of whom I have worked with and can vouch for.
OMB’s definition is: “Enterprise architecture is an agency-wide framework for incorporating business processes, information flows, applications, and infrastructure to support agency goals”. Substitute enterprises for agency and you have a solid EA definition.
Basically it is saying that you should first create a corporate-wide skeleton or framework upon which to incorporate present and future business operations, processes and data, and the means of supporting them, i.e., applications and infrastructure. This framework is the core of EA; setting direction for the company and a concrete reference point for corporate governance. That is, IT governance should use these same factors in constructing a governance system.
Next let’s look at what one of the earlier and, in opinion of many a landmark work, has to say on this subject – the Institute of Electrical and Electronic Engineers document entitled “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”. (A more common name is Specification 1471.)
1471 defines IT Architecture as “The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” While this specification is IT specific, the definition is broad enough to encompass many portions of the enterprise.
In 1471 terms, a system is all the applications and product lines of IT. Further, it says that a system inhabits an environment or context that includes the operational and political circumstances that influences development. Here we see that exogenous factors have an influence on the company and must be taken into account. Thus an IT architecture is not just a technical concept but is concerned with how IT is organized and the relationship of its parts to form a comprehensive entity which will be moved by and move the company toward its goals. While the actual IT applications, hardware, data, etc. are positioned by the framework, activities such as business processes influence the architecture.
At this point we should begin to notice that the elements of IT architecture are the same elements that are necessary to control IT and direct it towards beneficial behavior – in a word, Governance. To further emphasize this, notice that 1471 brings in the use of governing principles, which we discussed in the previous issue as a driving force for governance. So even though the goal of these specifications is to explain how to construct a well formed architecture, the very form of that architecture consist of those elements that comprise the elements of good governance.
From another viewpoint President Obama said in his speech of 12/1/09 – “Each proposal must be weighed in the light of a broader consideration: the need to maintain balance in and among national programs.” This concept applies equally well to constructing an IT architecture – your architects, as the architects of national programs, must be ever cognizant of the need to maintain balance. In IT, the balance is that between user interaction, cost, hardware and software components, while satisfying corporate business goals. Following the parallels we are establishing, this same type of balance is a critical component of governance.
Drilling down further, we turn to another specification, namely, TOGAF, The Open Group Architectural Framework. This specification breaks down IT architecture into four categories:
This description of architecture connects the major IT mechanisms with the more general emphasis on business architecture. TOGAF starts with the business structure and positions it as the motivating force for IT. Only then does it bring in the more IT specific items of data, application and Technical Architecture (i.e. IT infrastructure). These relationships should also be used in the construction of IT governance. Each of these architecture classes becomes the levers for directing and controlling the major output of IT. One example may make this clearer. Going back to the State Street principle, “One State Street” in the previous issue; it resulted in a change in State Street’s data architecture to have a consistent structure for all company’s customer data.
Returning to another concept in 1471 related to good governance, the specification says that the architecture should take into account the concerns of all the stakeholders, where stakeholders are defined as all the entities that effect and/or are affected by the IT system under discussion. Thus stakeholders encompass a number of people and entities beyond IT and even beyond the company.
Groups that come readily to mind as stakeholders are other departments, suppliers and customers. However, these are not all the parties and in some case not the most important. What about your investors and banker, the local and federal government? But the company’s potential reach doesn’t stop there, it is necessary to include the concerns of neighbors and the company’s effect on the environment. Any of these may cause grief if their concerns are not properly taken into account.
Stakeholders are an important and, in many cases, a critical consideration in establishing your governance system. How the company treats stakeholders greatly influences the direction that a company should take. Controlling IT outcome to treat the concerns of all stakeholders fairly is an essential building block of good governance.
Specification 1471 describes how to develop and write an Architectural Description, AD. These same concepts apply to putting IT governance in writing. In both cases a permanent record is necessary, both from a continuity point of view, so you don’t keep reinventing the wheel, and to avoid any misinterpretation or the “I didn’t know that” excuse.
One of the important concepts in writing the AD and governance documents is to establish a set of views of the stakeholders, where a view is a collection of related stakeholder concerns. Once the concerns are collected and grouped, the job is to assure that each view is addressed by the IT project under consideration. A complete AD, as well as a complete governance document, will be composed of a number of sub-documents, each addressing a pertinent view.
This is not an easy task, especially when we realize that stakeholders are as diverse as outlined above. In considering the broadened aspect, you may find some views that are in conflict with each other. When developing the documents it is important to find an optimum way to balance these conflicting views. Quality is determined by how well you satisfy these conflicting concerns. Another critical task is to identify and correct any areas of inconsistency between the solutions to different views and to include any views that might have been overlooked.
Finally, it is important to follow the IT Principles that have been previously developed. This keeps focus on the business goals. Yes, I know that we keep repeating this, but it is sine qua non for every aspect of IT governance.
Since an IT architecture is more technically oriented than that of IT principles, the architectural decision committees of the majority of successful companies are led by their technical executives. As pointed out by Weill and Ross, this structure is more complicated than that of the IT Principles committees we previously presented.
There are two variations that are in common use. One structure has a hub and spoke format, where the spokes consist of executives of the various business units and the hub the CIO and other IT executives. In this configuration the IT led committee meets separately with each of the business unit committees to obtain their input and jointly define the specifics of the governance system. Consistency with corporate business principles is maintained by the hub, since, in this case, they are the one group with a view across all the business units. This requires that your IT executives have a corporate-wide viewpoint. Don’t use this structure if your IT execs lack this viewpoint.
An alternate structure is a “T” format, where the configuration is that of two committees – the IT managers in one and top business executives in the other. The two groups meet separately, usually on the same day and then have a joint meeting. As opposed to multiple meetings, one for each business unit as in the hub and spoke, the “T” structure has only two committees, which is a simpler overall structure. While the “T” structure gives more attention to a centrally controlled IT, the former gives each business unit more individual attention.
Choosing the right structure for your company will depend on the direction that your IT principles send you, which in turn is dictated by your business goals and your operating model and the relative expertise of the participants.
As we have walked through the factors that the experts have recommended for a good IT architecture, we see that these recommendations are the same ones that make up concrete steps for good IT governance. In some respects IT governance and IT architecture are two sides of the same coin. The principles of IT governance should influence the construction of a good architecture, while the principles of a good architectural design make tangible many of the parts of IT governance.
Without an encompassing architectural description supported by strong governance, continuity and complementary output of IT efforts will be lacking and there is the strong possibility of parts of IT working at cross purposes, to say nothing of failing to support business goals.
Sometimes a negative example emphasizes the facts more that a positive one. One such example would be applications that solve some stakeholder’s concerns while neglecting the concerns of other stakeholders. Not only would there be holes in the architecture but IT output could actually cause harm to a neglected stakeholder, the opposite of what good governance stands for.
Our next newsletter will address the governance of IT Infrastructure.
Topics: IT Governance | No Comments »
Leave a Reply
« Cloud Computing on the Horizon | Home | How the Creative Class is Affecting the Way Businesses Think »
RSS Feeds
