Aggregated enterprise architecture wisdom
As the cloud computing adaption and maturity accelerates, a number of case studies of early cloud migration are emerging. Ironically most of such case studies often talk about success of such migration and dynamic business and technology benefits it de…
As the cloud computing adaption and maturity accelerates, a number of case studies of early cloud migration are emerging. Ironically most of such case studies often talk about success of such migration and dynamic business and technology benefits it de…
As discussed in Part 1, for me the primary value in Cobit 5 is the formalization of policy as a concept that has a life cycle and management process. In CBDI-SAE we have focused very strongly on defining the policy hierarchy and instances as the mechanism by which consistency is delivered and governed. Consequently over the years I have been critical of Cobit 4.1 because it was essentially promoting process based governance – if you are executing this process, with some nodding in the direction of general outcomes, then everything’s OK.
So I am very pleased to see policy introduced in a more coherent manner in Cobit 5. The 4.1 definition of policy was: “Generally, a document that records a high-level principle or course of action that has been decided upon. A policy’s intended purpose is to influence and guide both present and future decision making to be in line with the philosophy, objectives and strategic plans established by the enterprise’s management teams.”
In Cobit 5 the definition changes to: “Overall intention and direction as formally expressed by management.” This is better, but still not quite there. Contrast it with the CBDI-SAE definition: “A strategy or directive defined independently from how it is carried out.” I could ask what does management mean? If it was really necessary to include, then a reference to Governance Board, Design Authority or equivalent might have been helpful.
However, minor irritations aside, what Cobit 5 does is lay down a clear requirement for policy “to be part of an overall governance and management framework providing a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”. Further Cobit 5 separates Policy from Principle – a very important step. Also very sensibly Cobit 5 does not attempt to define policy instances, nor indeed the hierarchy and this allows specialists (such as ourselves) to map and or align our pre-existing hierarchy to the Cobit framework. I will return to and expand upon the hierarchy in the next part of this series. But first I want to consider policy nomenclature and structure in a little more depth.
Cobit 5 says “Policies provide more detailed guidance on how to put principles into practice . . .” This is potentially misleading. Yes policies are practical strategies and directives that support and realize principles, but to suggest they must be detailed is incorrect. Good policies should be formed as assertions that are true or false and should not be detailed with “how” they are achieved. The best policies are those that are mandatory – providing unequivocal direction to architects and service delivery teams. The detail is best left to Guidelines – or recommendations that indicate use of patterns and practices.
This simple error in Cobit 5 is actually a fundamental flaw that I would like to see fixed. Time and time again I come across confusion over the nomenclature being used by our clients to support governance. Confusion in this area leads to poor implementation and inconsistent governance. The terms policy, standard and guideline are very commonly used, but frequently mean very different things.
In this context, the good news is Cobit 5 has at least defined policy as the overall intention and direction. I will certainly be using this to advise my clients to standardize on this terminology. Guidelines should then be regarded as practice recommendations. These are not policies with a lower level of mandatory status. At some stage they may evolve to become policies, but not necessarily.
Standards are perhaps a little easier. The CBDI-SAE definition is “A collection of rules or practices which are relevant in Service Architecture or Engineering.” And for good measure the meta type Protocol is a subtype of Standard. Standards therefore are clearly defining the mandatory requirement to comply with specific protocols and practices in given contexts.
To summarize, Cobit 5 is a major step forward. It encourages a policy framework and nomenclature standardization on “policy” for the major directives and strategy assertions and doesn’t preclude complementary Guidelines and Standards under a common management process. In addition Cobit 5 provides the outline framework for development of a policy hierarchy and policy instances, which I will cover in some detail in the next part of this series of blogs.
References: Using Cobit 5 – Part 1 – Principles
Using Cobit 5 – Part 3 – The Policy Hierarchy
I am impressed with Cobit 5. The leap from 4.1 to 5 is significant and useful. Points to note:- the level of detail has been REDUCED!- Cobit has discovered POLICIES! The framework is no longer a purely process perspective, but recognizes a defined set …
As I found in our Enterprise Architecture team in Microsoft, each time an Enterprise Architect is assigned to a specific area of the business, each one has a unique “engagement” with their stakeholders. In very large organizations (like mine), there may be many different IT units as well as many different business units, all involved in a particular strategy. Each situation is different. This leads to a common problem that can framed with two questions:
We developed a simple grid that helps to position the EA with respect to a specific area of the business. The two axes of the grid are: Architectural Maturity of the “segment” and Maturity of the Architectural Engagement itself. Within each cell, we put a description of “what we want the EA to do” if they find themselves in that position.
Note that maturity of the engagement is a measurement of a relationship: specifically the relationship between the “business customer” and the Enterprise Architect. Architectural maturity of the segment is measured against both the business area and the IT groups that they use (see below). You need to measure the maturity of BOTH variables in order to understand what an Enterprise Architect will need to do to be effective.
Note that the Architectural Maturity axis has four levels, cryptically described as “Level I” through “Level IV”. This is a reference to our internal maturity model, which I’m not at liberty to share in detail.
The broad strokes are:
I’ll provide two scenarios to illustrate how this simple grid is used.
In Fabrikam, we are Enterprise Architects. Fabrikam manufactures and distributes consumer electronics. There are six divisions that manufacture different kinds of products (kitchen appliances, television and radio, automotive, etc). Let’s say that we have 18 Enterprise Architects in our EA team. Fabrikam’s EA has divided into three working groups, each with six architects. Maria manages one of these teams, and has six enterprise architects working for her. Her team focuses on addressing business issues related to supply chain management.
Maria is performing an annual review for two of her architects. They are Tomas and Jai.
Tomas is working with the kitchen appliance team. This is the oldest division in Fabrikam, and they have their own IT group that has been stable for many years. That team has established processes for IT architecture but no business architecture. Their architectural maturity is Level III. Tomas just moved over to the kitchen appliance division from the television and radio division. He is a well established architect with years of experience, but the kitchen appliance team is just beginning to get to know him. As a result, the maturity of the engagement is “Useful.”
The intersection of these axes has the following text:
Maria can set expectations with Tomas and with the Kitchen Appliance division. Tomas will be expected to engage in existing governance and review processes. He will be expected to work with business stakeholders in the kitchen appliance team as well as other divisions to address shared opportunities, capability overlaps, and strategic prioritization. He will be expected to collect current state information models, system models, technology models, and business strategies for the EA repository. He will be measured on his ability to deliver on these expectations.
Jai is working with the automotive division. This is the newest division in Fabrikam, and they are just beginning to roll out their first set of after-market automotive radios and CD players in the North American market. Their IT division is small and rather chaotic. Their architectural maturity is Level I. Jai has been working with the automotive division for about two years, and has repeatedly earned recognition from their business leaders for his skill and depth of knowledge. The maturity of the engagement is “Influential”.
The intersection of these axes has the following text:
Maria can set expectations with Jai and with the automotive division. Jai is expected to demonstrate EA specific methods and deliverables. The teams know him and trust him. He can demonstrate how EA can be valuable by simply doing the work and showing how valuable the results are. Due to his level of influence, he can work with the business to invest in an area of improvement that will benefit the entire enterprise (for example, a project to improve the distribution of finished goods to retailers), and then work with the IT teams and business stakeholders involved to get the project launched and oversee its development. Jai can be measured on his ability to deliver on these expectations.
In small organizations, Enterprise Architects can be “heros” and just “do what works,” but if you are trying to develop a mature EA program, each architect needs to have specific goals and specific deliverables that they will be expected to deliver. This kind of model, we found, is useful for helping each architect to position themselves and their role in the organization.
What are the values of a good enterprise architect? Being in a consulting practice where I spend the most of my working life collaborating with CIO’s, process owners, and senior architects, I often hear that question. Often the question emerges out of …
What are the values of a good enterprise architect? Being in a consulting practice where I spend the most of my working life collaborating with CIO’s, process owners, and senior architects, I often hear that question. Often the question emerges out of …
The recent “Common Approach to Federal Enterprise Architecture” (US Executive Office of the President, May 2 2012) is extremely timely and well-organized guidance for the Federal IT investment and deployment community, as useful for Federal Departments and Agencies as it is for their stakeholders and integration partners. The guidance not only helps IT Program Planners and Managers, but also informs and prepares constituents who may be the beneficiaries or otherwise impacted by the investment. The FEA Common Approach extends from and builds on the rapidly-maturing Federal Enterprise Architecture Framework (FEAF) and its associated artifacts and standards, already included to a large degree in the annual Federal Portfolio and Investment Management processes – for example the OMB’s Exhibit 300 (i.e. Business Case justification for IT investments).
A very interesting element of this Approach includes the very necessary guidance for actually using an Enterprise Architecture (EA) and/or its collateral – good guidance for any organization charged with maintaining a broad portfolio of IT investments. The associated FEA Reference Models (i.e. the BRM, DRM, TRM, etc.) are very helpful frameworks for organizing, understanding, communicating and standardizing across agencies with respect to vocabularies, architecture patterns and technology standards. Determining when, how and to what level of detail to include these reference models in the typically long-running Federal IT acquisition cycles wasn’t always clear, however, particularly during the first interactions of a Program’s technical and functional leadership with the Mission owners and investment planners. This typically occurs as an agency begins the process of describing its strategy and business case for allocation of new Federal funding, reacting to things like new legislation or policy, real or anticipated mission challenges, or straightforward ROI opportunities (for example the introduction of new technologies that deliver significant cost-savings).
The early artifacts (i.e. Resource Allocation Plans, Acquisition Plans, Exhibit 300’s or other Business Case materials, etc.) of the intersection between Mission owners, IT and Program Managers are far easier to understand and discuss, when the overlay of an evolved, actionable Enterprise Architecture (such as the FEA) is applied. “Actionable” is the key word – too many Public Service entity EA’s (including the FEA) have for too long been used simply as a very highly-abstracted standards reference, duly maintained and nominally-enforced by an Enterprise or System Architect’s office.
Refreshing elements of this recent FEA Common Approach include one of the first Federally-documented acknowledgements of the “Solution Architect” (the “Problem-Solving” role). This role collaborates with the Enterprise, System and Business Architecture communities primarily on completing actual “EA Roadmap” documents. These are roadmaps grounded in real cost, technical and functional details that are fully aligned with both contextual expectations (for example the new “Digital Government Strategy” and its required roadmap deliverables – and the rapidly increasing complexities of today’s more portable and transparent IT solutions. We also expect some very critical synergies to develop in early IT investment cycles between this new breed of “Federal Enterprise Solution Architect” and the first waves of the newly-formal “Federal IT Program Manager” roles operating under more standardized “critical competency” expectations (including EA), likely already to be seriously influencing the quality annual CPIC (Capital Planning and Investment Control) processes.
Our Oracle Enterprise Strategy Team (EST) and associated Oracle Enterprise Architecture (OEA) practices are already engaged in promoting and leveraging the visibility of Enterprise Architecture as a key contributor to early IT investment validation, and we look forward in particular to seeing the real, citizen-centric benefits of this FEA Common Approach in particular surface across the entire Public Service CPIC domain – Federal, State, Local, Tribal and otherwise. Read more Enterprise Architecture blog posts for additional EA insight!
Recently, I was contacted via this blog by an individual who had been challenged to set up a new Business Architecture practice within his company’s Enterprise Architecture team. He reached out to me to ask about some books to read and some…
Here we are at the final part in our hot discussion – will Agile and CMM get hitched, become a potent combination? If you have followed the earlier parts of this story, you would share my excitement – for the … Continue reading →
HP Distinguished Technologist E.G. Nadhan outlines factors that define the right way to use Cloud Computing for enterprise transformation. Continue reading →
In the first part of the discussion, drawing upon the genesis of Agile and CMM, we were left wondering if the two are “The Misfits”, and most likely to disappoint the pacifists, or can they become soul-mates after all. The … Continue reading →