Aggregated enterprise architecture wisdom
Metaphor For Generative TransformationGenerative Transformation is prompted by system. It is driven by the ecosystem in a top-down manner. Developing integrative effect the ecosystem creates invigorating environment, for those living within to start cr…
Many companies do not do governance well. A primary reason for this is a focus on governance “process” at the expense of policies. And, where policies are established, it is common to observe a surfeit of bad, inconsistent policies that are overlapping and generally ignored. As a result much governance is carried out by opinion; and governance decisions are not easily repeatable.
The Cobit 5 framework provides reference models for process and goals but, other than providing very general guidance, stops short of any detail at all relating to principles and policy. However in fairness Cobit 5 does recommend “a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”.
So what does a policy hierarchy look like? Does each organization need to invent its own unique structure and content? Actually we need more than just a policy hierarchy, we need a model that helps us establish a consistent approach to policy search and description. And whilst every organization will have unique needs, much of the hierarchy and policy content will be reusable. What will usually be highly customized are the contexts and their relationships with policy assertions.
In the diagram:
– policy type – classifies the policy. It can be hierarchic.
– policy subject – identifies the focus of the policy the class of object being governed.
– policy – a strategy or directive defined independently from how it is carried out
– policy assertion – is an atomic policy requirement, expressed as a statement that must be true or false
– policy context – an entity that limits the reach of a Policy.
– policy effect – an intended and/or an actual outcome of a Business Policy. This can be the Principle(s), Goal(s) or Outcome(s), which of course map neatly to Cobit 5.
Let’s look at an example:
| Meta Class | Example |
|---|---|
| Policy Type | Architecture |
| Policy Subject | Application Architecture |
| Policy | Interfacing |
| Policy Assertion | All new Application Interfaces must be loose coupled. |
| Policy Context | Global applicability |
| Policy Effect | Principle: Interoperable; IT Goal: Agility |
Now to put this more broadly into the Cobit 5 context, here’s a fragment of a policy hierarchy, mapped to Policy Subect and Cobit 5 IT Goals.
The policy hierarchy shown above is not rocket science. However it facilitates consistency and communication to all the various stakeholders. You could at a stretch manage policies in a spreadsheet, but in practice it would be advisable to use something like Sharepoint or an equivalent, that allows you to manage the life cycle, status and so on. In a further elaborations of this little series of blog posts I will explore policy relationships with guidance and standards, policy assertion and context development plus the broader policy management model.
Reference:
Using Cobit 5 – Part 1: Principles
Using Cobit 5 – Part 2: Policy Nomenclature
Next Step: Talk to David about how to apply effective, policy based governance.
Haven’t been to New Zealand yet, but I will be there soon… From September 4 through 7 in Auckland, for TechEd New Zealand. I will be presenting two topics (Business architecture for non architects, and Aligning IT with capabilities).
Now, normally you wouldn’t see Enterprise Architecture topics on a TechEd calendar. However, in the NZ market, there just isn’t the demand for multiple Microsoft conferences every year. As a result, all the conference demand is bundled up into TechEd. Due to the efforts of Terry Chapman and the hard working architects in Microsoft New Zealand, the TechEd conference there has developed quite a reputation for hosting an advanced architecture track.
I’m fortunate to be attending and presenting. If you live or work in the region, I’d love to see you at TechEd New Zealand. If you would like to see more information about the sessions at TechEd NZ, click here.
These are interesting times for CIOs in the Federal sector. Budgets are going down and demands are rising as mission customers are increasingly aware of how technology can impact their mission performance. Many CIOs have turned to philosophy … customer engagement philosophy that is. CIOs are wrestling with: how should their OCIO engage its customer base how should they measure customer satisfaction how should their organization be configured to best […]
Developing Enterprise Architecture Competencies from sboray
How can you use the tools of Enterprise Architecture and open standards to improve the capability of your company doing business? The Day 2 speakers of The Open Group Conference in Washington, D.C. addressed this question, focusing on Enterprise Transf…
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…
Make the day enjoyable! Doing my work outdoor with a hot drink.Have you ever invested a lot of effort to get into your dream college but then sloughed through it because there were just too many interesting classes and you ended up taking more than you…
Make the day enjoyable! Doing my work outdoor with a hot drink.Have you ever invested a lot of effort to get into your dream college but then sloughed through it because there were just too many interesting classes and you ended up taking more than you…
It is time to announce the winners of the Washington, D.C. Photo Contest. For those of you who were unable to attend, conference attendees submitted some of their best photos to the contest for a chance to win one free conference pass to one of the glo…
by: Bill Cason – Troux CTO – July 31st, 2012
Gathering and assessing data can be quite seductive. But it’s the equivalent of modelling the
universe, and it’s a recipe for disaster. In fact if we see any problem today in our EA deployments, it’s that people get so excited they want to gather all their data at once. This is the last of the Top Three common mistakes Enterprise Architects (EAs) make when starting (or re-starting) a program. I call this “Building the Answer Machine” – and it doesn’t work.
In this scenario, you are asking people for more data than you need, without any scope control or business value focus. Obviously you don’t want to collect data, just to see what you can find.
Instead, consider these three recommendations when embarking on a data gathering effort. They will help you successfully identify and gather the data that is most important to your business. #1- Leverage a wider team with a focus on business value to help you identify which data is critical. #2- Automate as much of the data collection process as possible. #3- Market your success internally so that contributors appreciate the fruits of their labor and are more inclined to embrace the data gathering effort moving forward.
Leverage a wider team
You will have lots of stakeholders and constituencies requesting answers. You can quickly lose sight of being able to deliver value in a timeframe that is acceptable to management. Queuing up priorities and managing scope control is hugely important. Otherwise you will have plenty of stakeholders disappointed by your inability to answer their questions.
The EA team is responsible for creating business value with the information that is collected. But don’t waste EA resources gathering that information. With executive sponsorship in place, the enterprise will see it as a priority to identify data stewards. The data stewards will then provide the required data you could not automatically collect. This in turn ensures EA resources are focused on analyzing the quality of the information, and identifying gaps in order to initiate the decision-making process.
Automate data collection process
Based on my team’s experience, as much as 80 percent of the information required to initiate an EA program already exists in the enterprise. In many cases, you can automatically collect important information from other IT and business planning repositories so you don’t have to expend human resources to find what’s already being managed. That said, stay focused on collecting only the information necessary to answer the high priority questions your business wants to address.
Market your success
Don’t forget to market your success internally. You secured support from the organization by promising something good for them, so make sure you go back and tell them you did it. Then the organization as a whole can share in your success.
When you gather all this information and start to see results – in this case the answers to critical business questions – share those results.
Remember, the data acquisition process is accretive. The data you get to answer the first set of questions becomes foundational for answering the second set of questions. You don’t use information, throw it away and stop asking questions. By involving the wider team, you empower and encourage people to embrace the EA processes and use the output to change the business.
We already know that organizational change is one of the hardest challenges any company can embark upon. Ensure you are taking the right steps by aligning a wider team to provide information, automating the data collection process, and marketing your success internally. The EA practice can then deliver true organizational change in a focused and organized manner, on a timeline management expects, and with the support of both your executive sponsor and the whole of the enterprise.
Read other articles in this three-part series: How to avoid common mistakes with your EA Program:
