Aggregated enterprise architecture wisdom
Why is it so hard to prove the value of generalist disciplines such as enterprise-architecture? And what can we do in practice to resolve this challenge? As I see it at present, there are three distinct yet interrelated parts to…
Yes, I admit it, I made that classic mistake again: I allowed myself to get engaged in an EA discussion on LinkedIn… This one started from the – to my mind – absurd and then insulting notion that EA is…
On one particular programme the question arose whether to create the “Enterprise Architecture” or the “Requirements” first has been a matter of great debate. On the one hand, the organisation in question did not have an Architecture and yet the organis…
On one particular programme the question arose whether to create the “Enterprise Architecture” or the “Requirements” first has been a matter of great debate. On the one hand, the organisation in question did not have an Architecture and yet the organis…
I just recently had a conversation with a talented enterprise architect who had brought together the EA framework elements from numerous different sources in order to address the needs of his business. Included in that list was the Enterprise Bus…
What’s the boundary of the organisation? Boundary in what sense, and for whom? And how does this impact on enterprise-architecture and the like? These questions came up for me a short while ago when working on an article on enterprise-architecture…
One of the core tasks in enterprise-architecture is sensemaking – making sense of what’s going on within some context. And one of the key methods we can use for this is to make some kind of mental-map of what seems to…
By Henry Franken, BIZZdesign Models have played an important role in business for a long time. Process models, information- and data models, application landscapes, strategic models, operational models – you name it, organizations have tried it. …
The next 5 months portend a spectacle of US Congressional battles to be waged ahead of the pending, mandatory “sequester” – automatic, mandatory federal government spending reductions of about $1 Trillion over 9 years, in non-exempt, discretionary appropriations, set to take effect 1/2/2013. Forward-thinking planners in government IT organizations, in large Programs that depend upon IT, and among the Systems Integration (SI) community are likely to dust off Enterprise Architecture skills for analyzing budget cut implications across their IT investment portfolios, and possible cost savings opportunities to offset them. Leveraging a methodical, EA-guided approach to both assess impacts and adjust spending priorities, while illuminating new areas of savings, is a sure route to mitigating serious risks and delays to delivery of critical citizen services.
Whether you’re dusting off the existing EA artifacts, or need to take a very rapid, optimized route to constructing initial enterprise IT models, the driving principle at this time will be rapid, absolute reduction in complexity with a clear line-of-sight to cost savings. “Complexity” here simply refers to an inefficient or needlessly detailed volume of time and resources applied to deliver IT solutions – time spent re-engineering processes, building redundant interfaces and monitors, installing hardware & software in a piecemeal fashion.
Driving complexity, and therefore introducing cost savings, out of engineered systems is the central tenet of “Value Engineering” – “the optimization of a system’s outputs by crafting a mix of performance (function) and costs”. Essentially, deliver the same capabilities with better value by driving down the cost to build and/or operate. Section 52.248-1 of the FAR (Federal Acquisition Regulations) describes the “Value Engineering Clause” that is inserted into many large Federal IT contracts – enabling the contractor to propose changes to the system being developed (i.e. a “Value Engineering Change Proposal”, or VECP). If the proposal is accepted, the actual or collateral savings derived by the government (through cost modification to the contract) can be shared with the contractor. It’s a win-win opportunity for the government, system beneficiaries and the contractor community to discover and propose engineering changes that will lower costs, yet still deliver the same or better results.
Many VECPs are submitted for technology assets – i.e. contained systems that may work better when newer, less-costly components are substituted…like missile systems or electronic devices. This may be because the contractor typically is the sole source of knowledge and research concerning how to optimize and build the components, the “value” and function of the asset is very clear (i.e. it’s delivered and explodes on target) and constant innovation is a demand of the environment. VECPs are also submitted for IT systems and programs, though it’s much more difficult to identify and propose the specific cost savings or cost avoidance that might result – since IT systems are frequently dependent upon many external or interfaced elements, vendor products and processes.
An EA-centric review of a program or line-of-business IT investment may quickly yield insight that would lead to specific value engineering opportunities, and therefore reductions in IT costs. For example, a particular set of information may be created, shared and recreated across several systems, using different processes, datastores and technologies. An segmented EA approach driving down from the particular business, process and information domains, may quickly illuminate targets of opportunity for database or interface consolidation – and therefore potential consolidation of supporting technologies (i.e. storage, networking, processors). This may lead to optimized technical operations and business process performance, which can be clearly mapped back to the Enterprise Architecture to validate that governance and mission requirements are (still) met, cross-enterprise risks are mitigated, and IT investment portfolios and procurement activities are properly adjusted or re-aligned.
With this kind of information, a VECP could be constructed that very clearly proposes both program-specific and collateral (i.e. across the rest of the enterprise) savings resulting from introduction of state-of-the-art consolidating technologies (for example, pre-integrated, self-contained and consolidated database engineered systems, perhaps cloud-enabled). At the very least, an EA view can help identify and prioritize targets of opportunity for Value Engineering that may become part of an effective and timely sequestration response – both before and after such an event, and in fact as part of the annual capital planning and investment control (CPIC) processes.
The next 5 months portend a spectacle of US Congressional battles to be waged ahead of the pending, mandatory “sequester” – automatic, mandatory federal government spending reductions of about $1 Trillion over 9 years, in non-exempt, discretionary appropriations, set to take effect 1/2/2013. Forward-thinking planners in government IT organizations, in large Programs that depend upon IT, and among the Systems Integration (SI) community are likely to dust off Enterprise Architecture skills for analyzing budget cut implications across their IT investment portfolios, and possible cost savings opportunities to offset them. Leveraging a methodical, EA-guided approach to both assess impacts and adjust spending priorities, while illuminating new areas of savings, is a sure route to mitigating serious risks and delays to delivery of critical citizen services.
Whether you’re dusting off the existing EA artifacts, or need to take a very rapid, optimized route to constructing initial enterprise IT models, the driving principle at this time will be rapid, absolute reduction in complexity with a clear line-of-sight to cost savings. “Complexity” here simply refers to an inefficient or needlessly detailed volume of time and resources applied to deliver IT solutions – time spent re-engineering processes, building redundant interfaces and monitors, installing hardware & software in a piecemeal fashion.
Driving complexity, and therefore introducing cost savings, out of engineered systems is the central tenet of “Value Engineering” – “the optimization of a system’s outputs by crafting a mix of performance (function) and costs”. Essentially, deliver the same capabilities with better value by driving down the cost to build and/or operate. Section 52.248-1 of the FAR (Federal Acquisition Regulations) describes the “Value Engineering Clause” that is inserted into many large Federal IT contracts – enabling the contractor to propose changes to the system being developed (i.e. a “Value Engineering Change Proposal”, or VECP). If the proposal is accepted, the actual or collateral savings derived by the government (through cost modification to the contract) can be shared with the contractor. It’s a win-win opportunity for the government, system beneficiaries and the contractor community to discover and propose engineering changes that will lower costs, yet still deliver the same or better results.
Many VECPs are submitted for technology assets – i.e. contained systems that may work better when newer, less-costly components are substituted…like missile systems or electronic devices. This may be because the contractor typically is the sole source of knowledge and research concerning how to optimize and build the components, the “value” and function of the asset is very clear (i.e. it’s delivered and explodes on target) and constant innovation is a demand of the environment. VECPs are also submitted for IT systems and programs, though it’s much more difficult to identify and propose the specific cost savings or cost avoidance that might result – since IT systems are frequently dependent upon many external or interfaced elements, vendor products and processes.
An EA-centric review of a program or line-of-business IT investment may quickly yield insight that would lead to specific value engineering opportunities, and therefore reductions in IT costs. For example, a particular set of information may be created, shared and recreated across several systems, using different processes, datastores and technologies. An segmented EA approach driving down from the particular business, process and information domains, may quickly illuminate targets of opportunity for database or interface consolidation – and therefore potential consolidation of supporting technologies (i.e. storage, networking, processors). This may lead to optimized technical operations and business process performance, which can be clearly mapped back to the Enterprise Architecture to validate that governance and mission requirements are (still) met, cross-enterprise risks are mitigated, and IT investment portfolios and procurement activities are properly adjusted or re-aligned.
With this kind of information, a VECP could be constructed that very clearly proposes both program-specific and collateral (i.e. across the rest of the enterprise) savings resulting from introduction of state-of-the-art consolidating technologies (for example, pre-integrated, self-contained and consolidated database engineered systems, perhaps cloud-enabled). At the very least, an EA view can help identify and prioritize targets of opportunity for Value Engineering that may become part of an effective and timely sequestration response – both before and after such an event, and in fact as part of the annual capital planning and investment control (CPIC) processes.
For enterprise-architects, the Olympics provides a great illustration of the difference between ‘the enterprise’ and ‘the organisation’. Although in business it’s quite common to regard ‘enterprise’ and ‘organisation’ as synonyms for each other, for enterprise-architecture its wisest to use the…
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.