This is a draft article entitled “Building an Effective Business Architecture and Metrics Capability”.
Category: Enterprise Architecture Page 2 of 3
At the risk of being controversial, I don’t believe enterprise architecture is about “alignment between IT and the business”. While there is not doubt that an effective enterprise architecture practice will improve this sort of alignment, it needs to do more than improve the standing of IT or the percentage of the value pie that IT gets credit for.
Enterprise architecture is a process. But it’s not a process of creating as-is architectures, creating to-be architectures, and then creating transition roadmaps. These are useful deliverables and will indeed be produced – but they are no more enterprise architecture than a MS-Project plan is project management.
The process of enterprise architecture is about identifying the activities, information, or assets that you want to standardise and then managing the level of standardisation actually achieved. It’s also important to note that this process occurs regardless of whether or not the process is called enterprise architecture.
If you look for it, this generic process of standardisation is everywhere. Even the idea that organisations have ‘products’ and ‘services’ is a form of this standardisation. It doesn’t require an enterprise architect to see how it would be beneficial to have some standard definition of what you do for your customers.
Another example is in the familiar department structures we see in most organisations: HR, finance, IT, etc. It has been determined in the past – and may well still be true – that it makes sense to standardise how, for example, payroll is processed. So you have a payroll department rather than all business units separately designing payroll processes. It also makes sense that you’d want to standardise the way products are matched with customers. Although increasingly separate strategies in the information age, this standardisation is traditionally achieved in this case by centralising these activities into a marketing department.
This standardisation in department groupings helps to align each organisation’s capabilities with the dynamics of the labor market. It also promotes efficiencies through specialisation and definition of labour. It may not always be the case, but this generic continuous process of standardisation has created these particular groupings because there is value in standardisation in these areas.
Information technology – in the general broad sense that includes processes and methods, but also in common usage as technical I.T. Information Technology – also plays a role in this standardisation process. To use the payroll department as an example again, it is not uncommon to implement the end-to-end payroll processes beyond what is performed by the payroll department into an ERP package such as those provided by SAP, Oracle, JD Edwards, etc. This is a process of standardisation.
The real value of enterprise architecture is recursive and somewhat tautological. Enterprise architecture is a standardisation of the process of standardisation. It is an attempt at defining how this on-going process of standardisation can be managed. It’s not perfect, but it’s all we have as a method of managing this process of standardisation with any formality or openness.
Enterprise architecture as an overall integrated framework helps to standardise by providing standard categorisations, definitions, and layers in which standardisation can be achieved. For example, Technical layers allow for standardisation of platforms, infrastructure, etc. Whereas Application layers provide opportunities to standardise integration approaches, services, types of common application functionality, etc. At the Information layer it is standardisation of the definitions of information items that are important so enterprise architecture frameworks assist with that.
In all cases above, the benefits of effective standardisation include reduced costs, increased agility, reduced risks, and an increased capacity for innovation. The special challenge of the Business architecture layer is twofold. Firstly, it provides context for the other layers. Particularly for information and application layer standardisation, it is the only way to understand ‘effective’ standardisation of those other layers. Secondly, the business architecture needs to identify the areas where investment [in standardisation] will deliver the greatest value.
When is comes to business architecture the standardisation process revolves around ‘capabilities’. Remember, organisations will keep on operating regardless of what the enterprise architecture team does. So capabilities may be existing areas where investments can be made, or potential areas based on analysis of the organisation’s customers, strategies, and other capabilities.
Not all capabilities are equal, and the types and degree of benefits that can be obtained through investment will different. However, if you don’t know what your capabilities are then you can’t make decisions about which to focus on and which to ignore. The next blog entry will focus on business capability mapping and how it forms the core of the enterprise architecture effort.
There are two important themes in the MWT Model that are used to shift organisational habits. These are ‘pendulum arguments & something else’ and ‘ideal realised strategies’. Pendulum arguments are issues like the ‘centralise or decentralise’ debate that cause organisations to continuously cycle through organisational design or financial control models. These pendulums must be fixed with ‘something else’ – such as an operating model or a collaboration architecture in this case.
Ideal Realised Strategies are a separate category. These are the problems when a strategy is proposed or in place that only delivers an acceptable balance of benefits and risk if it is implemented perfectly (which of course number happens). In the context of the MWT Model, these are usually management strategies such as ‘ensure you confirm that you have closed all issues by the milestone date’.
Ideal Realised Strategies often have unstated dependancies or are otherwise unfeasible. Ideal Realised Strategies also tend to keep people in positions of power because they need to be continuously funded and supported while the strategy endlessly edges towards perfect implementation.
As I spend some time thinking about enterprise architecture I’m starting to see the whole practice of enterprise architecture as an Ideal Realised Strategy. I was also struck by title of this article (“What to enterprise architecture and socialism have in common”) and as a Mises-head of sorts didn’t like the comparison.
I usually place enterprise architecture (EA) as the anti-thisis of the overtly political approach to organisational design and decision making inherent in the managerial approach. But not everybody places EA in this context, and it sometimes appears that as EA ‘matures’ to prescribe governance and business architecture approaches it is increasingly making its success dependant on more total control of the organisation.
Any strategy that has its success based on increasingly total control of the organisation that it supports is by definition an Ideal Realised Strategy.
Once I see EA this way I can’t help but think that it’s also evolving into a form of technocracy in the same way I have argued that managerialism is technocratic. It also risks becoming part of a pendulum argument in the way I have seen organisations swing from sales lead (“if we don’t sell anything it doesn’t matter what we deliver”) to delivery lead (“if our delivery suffers our clients won’t want to buy our product no matter how good our sales people are”).
EA is changing – needs to change – but let’s get this right.
Update: there are some nice hints towards an EA approach less obsessed with centralised power in the Gartner press release I’ve previously referenced.
I think innovation requires just four things:
1. idea management process – i.e. go from suggestion box-to-value creation
2. a reward mechanism – where the ultimate reward is working in an innovative company
3. scanning – i.e. scanning internally and externally for trends and small ideas that need to be nurtured
4. a structured approach to analysing the organisation to determine where to apply innovation
I think the structured approach bit (#4) is often missed and without it how do you grow or evaluate your ideas?
As an IT guy I know enterprise [business] architecture is the answer to this.
However, for a more general audience I think this approach is very interesting (free PDF book extract to download):
Very, interesting… I wonder, and I presume I guess correctly, who this is:
“I understand that a major Australian Bank has used this book as its “bible” for its current transformation, which includes the replacement of 30 year old core systems. Their objective is to be able to change business models in 20 minutes. With RWR’s vision implemented; if that’s possible, it might be doable. But I say good luck to them. It’ll be interesting to revisit them in 12 months.”
– from Angry Architect
The book in question is Enterprise Architecture as Strategy, which I think is a profoundly interesting approach.
“Airlines are notoriously cyclical because revenue is very sensitive to changes in demand. Profits are greatest when strong demand results in full planes (‘‘load’’) and high prices (‘‘yield’’), but they can disappear quickly when demand falls because costs are relatively fixed and flights can’t easily be cancelled.”
I’m currently working on the very edges of the airline industry (via IT outsourcing). I can relate to the ‘aeroholic’ tag. It’s a very compelling industry and while I don’t invest money in it I certainly invest time in it.
So, somebody important let me under his umbrella this morning. I spoke briefly to him and it got me thinking about Boston Consulting Group (from where he had worked as an adviser to Qantas for 10 years).
I think the airline industry’s highs and lows have been managed through sophisticated financial devices (fuel hedging, for example, or deferred losses). This is by necessity, but I think this process might have had it’s own unintended consequences.
I’m currently focusing on what those unintended consequences might have been… because that is where I will be able to have the greatest impact. There are some non-optimal behaviors and outcomes I have noticed. I think if I understand them in terms of the necessities above things will make sense …
Management, as a discipline, has a problem it can”t solve. It needs to coordinate separate but related activities caused by the division of labour. And it needs to be able to do this regardless of how labour is divided.
Project management, in particular, has this problem. I’ve said before that project management is a perfectly reasonable discipline as long as it doesn’t try to cross organisational boundaries. This is why project management is necessary but not sufficient in managing outsourcing.
Likewise, program management – which the discipline likes to define as the management of multiple related projects – isn’t really a separate discipline because of the scale of the work or the number of projects, it’s a separate discipline because multiple projects have multiple project managers.
Unfortunately, the accepted tenets of management simply do not scale. Multiple managers causes more problems than they solve – and therefore situations which require multiple managers need other practices to govern them.
The root of this problem is that ultimately, the discipline of management doesn’t in itself offer any useful advice on how to divide labour. It takes it as a given that labour is divided and then attempts to coordinate that.
Equally, managers – when you switch them on and give them responsibilities – tend to manage to those responsibilities. Good so far, but if the division of responsibilities isn’t right there is a problem. The problem might even get bigger if the managers are better.
But there are right and wrong ways to divide labour. Some activities are autonomous and some aren’t. Dividing management responsibilities and activities has its own additional challenges.
Only ‘architecture’ (which I define in this context as deliniated shared understanding) can offer any help in the actual division of labour. However, architecture must be domain specific. In order to determine correct/incorrect or efficient/inefficient divisions of labour it must take into account the domain and the required outcome.
(by the way, if you think a ‘strong management team’ solves this problem check out my article on ‘Management Teams as Cartels’)
Is the enterprise architecture a town plan? I’m not sure I agree with the idea that the enterprise architecture is analogous to a town plan. For example, under the work-in-progress ‘Coherent Enterprise Archiecture’ (CEA) e-book maintained here, the follow definition applies:
“The CEA strategy [is to] to lay out the Notional and holistic enterprise master plan at the high level, establish the common foundation and building blocks at the low level. The high level master plan serve[s] as the master [guideline] similar to a city plan for a city for holistic consideration. The low level common foundation and building blocks enable agility and simplicity. “
This idea of a ‘master plan’ leads the discussion into teritory best avoided. It is at odds with the MWT Model in that it is planning rather than market/architecture focused It implies that development of the enterprise architecture is a planning process that might result in a plan that should be executed.
Where the town planning analogy is helpful is in zoning. In this respect the town plan is useful in that it enables decisions. The enterprise architecture, rather than containing the organisation, enables decisions about the organisation to be made.
It also allows for anybody to raise an exception by means of identifying the a zoning law is being broken. Not only that but it’s the basis for configuration management for the town because making changes to the town will require various notices to be posted depending on zone that relates to the proposed change.
You can see other parts of the CEA framework address Buy In (http://www.liteea.com/lea.php?catid=298&blogid=1). This seems to imply that somebody else is deciding an enterprise architecture presenting it for approval. This isn’t really the purpose of EA. The purpose of EA is to allow joint decision making at the executive level.
An ‘architecture’ under MWT definition is a deliniated shared understanding. A collaboration architecture is a delinitaed shared understanding specifically for collaboration. In the case of enterprise architecture, this is collaboration during the executive decsion making processes on business process sharing and/or standardisation and data sharing and/or standardisation (which in today’s world tends to be technology spend and TEBT (http://www.managewithoutthem.com/tebt).
I’m not picking on CEA here. I think it’s well thought out and it represents a very useful ontology providing terms of reference talking about enterprise architecture. However, as I’ve said before an ontology is not a management process in itself. More importantly, the process of execution is likely to not be isomophic to the solution under development. The process is in fact likely to look conceptually like the opposite of the solution.
So while the CEA material (again, referenced here http://www.liteea.com/lea.php?catid=135&blogid=1?) effectively shows a hierachy of ‘master plan’, ‘segement architecture’, ‘solution architecture’, and ‘building blocks’ these are trying to build a picture the enterprise which fits together. Which is interesting, important, and certainly descriptive of the enterprise – but is it the enterprise architecture?
Specifically, regarding the idea of a ‘segment architecture’ I’ve seen discussion (such as here http://it.toolbox.com/blogs/lea-blog/what-is-segment-architecture-25945) which describes the rational as:
… EA [utilises a] segment architecture approach rather than the traditional big bang effort. It is a divide and conquers approach to enable incremental and continuous enterprise architecture effort based on business owners need.
This approach may be in fact become nessecary for the same reasons I’m coming to which relate to people trying to do to much in the descriptive aspects of EA and not enough in the aspects relating to the enabling of collaborative decision making. But it doesn’t tell me what enterprise architecture actual is – it only narrows the scope you are applying the definition to.
So the history of how we view EA has determine that we need to break it up into segment architectures; but the fact remains that a segment architecture is not an enterprise architecture. More importantly one particular organisation I work with takes it’s segmentation strategy very seriously – having spent considerable time aligning financial treatments to segment boundaries to allow segment level reporting of financial data. This organisation would require both segement architectures to allow decision making at a segment level and also a true enterprise architecture (not simply the sum of the segments) to enable discussions around the unification of value across segments and to reduce the risk of segment based performance optimisation at the expense of enterprise performance optimisation.
In recent communications to this particular client I have tried to raise the point that the conversations about how to apply the financial rules during the transition to segmentation have created value but that unless these conversations continue via the mechanism of enterprise architecture (not segment architecture) there is a risk that value will be los through independant optimisation of performance of the type described above (at the segment level).
Where is platform architecture?
If you want to delve into the details underneath the enterprise architecture you could ask ‘where is the platform architecture’? Where have the decisions been made on which platforms will be the standardised for particular functional areas (be it business functions, integration functions, storage, etc)? This could also be called a technical reference architecture. But again, this misses the point of why I think this approach to EA is wrong.
What if you just had an enterprise architecture?
I have prepared a simple enterprise architecture for a client I’m currently working with. It is not the ‘master plan’. It is not divided into particular segments (except where they are formally seperate and independant business entities) – and may never be. It does not yet trace to a system architecture of any description. Nor does it describe any particular platforms, applications, technologies. There are a few IT related terms in the architecture but these relate to specific areas of functional groupings such as enterprise event management and shared data access which are important to the organisations operational processes.
Some people would say I have created an ‘enterprise business architecture’ and that this is just part of the enterprise architecture. But why is it only part? An application architcture doesn’t need to contain the code. The application architecture can be delivered without the code – so why can’t the enterprise architecture be delivered without the application architecture!?
I have updated the MWT/TEBT Enterprise Architecture Worksheet (pdf). The major change is that I have included a better template diagram. I have also included some references to the Enterprise Architecture As Strategy book which make it clear that a different diagram template is probably required for enterprises with different operating models. The worksheet is now suitable for a unification operating model as defined in the EA as Strategy book.
The reason for the update is that I have been trying to visualize the enterprise architecture of a client organisation I am working with and this process has helped my thinking. I’m a big supporter of the approach to Enterprise Architecture prescribed in Enterprise Architecture as Strategy. However, the client I am working with at the moment that has a number of important characteristics which don’t come out very well in the example and template EA ‘core diagram’ formats show in the book.
The book itself isn’t about a modeling notation so it doesn’t actually prescribe a specific diagram style. It’s focus in more iterative development of the enterprise architecture and the sequence of components to focus on during development of the architecture.
The organisation I am working with, while certainly operating under a Unification model at the highest level, has a number of unique pillars in their competitive strategy which don’t come out when taking the book’s approach. So I have altered the generative sequence for EA development in this organisation.
Firstly, the unique strategic pillars for this organisation are:
- High need for operational capital
- Resulting in a need to support the organisation’s share price
- Resulting in a business segmentation strategy to increase visibility of value to the market
- Need to manage markets and customer types across two distinct operations in order to remain competitive
- Need for detailed product accounting to ensure accurate profitability of each ‘product’ can be determined
- Need to be able to quickly change ‘product’ mix across two operations
- A natural fit to a service oriented business architecture
Because of this I have developed a template EA core diagram structure which takes these into account. I believe it works very well for this organisation and others like it. I have included the diagram to the right with a full sized version (as well an overview of it’s main zones and analysis patterns) available in the pdf file.
Whenever I read about enterprise architecture I’m always struck by how technical the conversation seems. I’m not anti-technical; but in my mind architecture is more important than what we generally call management. This is also implicit in the principles of the MWT Model. It is in fact architecture which I see as the centrally coordinating mechanism of organisations rather than management.
This means that at the specific level at which you are coordinating the architecture needs to be understood by all participants – not just technical people. If the level of coordination is the executive team making IT investment decisions the particular architecture is the enterprise architecture.
Now I’m the first to complain when IT Management becomes a race to the bottom and when IT Managers wear the statement ‘I’m not a technical person’ as a badge of pride (isn’t management ‘technical’?) but I’m talking about something different and specific here. If enterprise architecture has an intended audience that includes so-called non-technical people it cannot be technical.
The problem is, I find that enterprise architecture is always defined as something too all encompassing. It is always defined inclusively of all the business processes, goals, objectives, technologies assets, etc of an organization. It’s almost defined as something that isn’t valuable until it is complete at all of these levels.
However, this causes immediate problems that are reflected in every analysis of enterprise architecture (or failures in EA effort) that I ever read. It always appears to be that EA efforts fail because they are not maintained, through ‘lack of governance’, or that they are misunderstood or ignored by senior management.
Analysis of EA effort actually spent is one thing, but other field reports indicate that the effort never even officially gets off the ground before it’s too difficult to define the ROI of the investment. Nobody seems to question the ROI of dedicating resources to blocking and passively obstructing enterprise architecture efforts but that is another issue altogether.
I think the solution to these problems is very simple. It’s a solution that eliminates the high-cost of enterprise architecture initiatives (and therefore the issue of ROI), it also helps incorporate enterprise architecture efforts into the rest of the organisation (therefore making alldesign effort enterprise architecture effort), and it takes enterprise architecture to the board room (or at least the CIO’s office) where it belongs.
The three fifteen step plan for solving your enterprise architecture issue is as follows:
- Hire a real enterprise architect
- Establish only ‘dotted-line’ reporting to the enterprise architect
- Use the phrase ‘enterprise architecture’ only to refer to ‘enterprise business architecture’
- Establish ‘planned traceability’ from the EA to project documentation
- Establish ‘planned traceability’ from the EA to system documentation
- Establish ‘planned traceability’ from the EA to software development life-cycle (SDLC) documentation
- Hold a workshop to established a baseline enterprise [business] architecture
- Schedule reviews of traceability each 6 months for each application system
- Include traceability reviews in the organizations project methodology at each phase gate
- Schedule a review of the baseline enterprise [business] architecture yearly
- Report, monthly, all EA traceability analytics
- Publish a quarterly analysis of EA traceability analytics
- Publish a whitepaper on how to interpret EA traceability analytics
- Co-sponsor at least one project concept / idea per year with a business growth outcome based on EA-level transformation
- Sponsor at least one project concept / idea per year with a IT efficiency outcome based on EA analysis and / or improving one or more measured based on traceability analytics
The most important step here is that you are no longer defining EA as a complete, integrated, end-to-end, endeavor. You enterprise [business] architecture is complete by step 7 above. It’s done. The assumptions about how value in the enterprise is generated are defined. The definition of enterprise architecture is also re-defined as only the enterprise [business] architect + the planned traceability to other key assets. In this sense, your EA is complete.
Steps 8-10 ensure that your enterprise architecture is always up-to-date. But up-to-date shouldn’t be read to mean complete. The EA is up-to-date in the sense that the enterprise [business] architecture is up-to-date and you know the status of all traceability. Within the status of the traceability is the key to understanding how complete you understanding of systems is – including the completeness ‘alignment’.
Steps 11-13 ensure that the information in the EA is known, understood, and utilised for decision making. Steps 14-15 ensure that the enterprise architecture (and the enterprise architect) delivers value. It also allows for additional specific, targeted EA effort to be managed through the normal project approval processes.
If the following steps are followed – and this of course depends on you finding a ‘real’ enterprise architect to hire – you will be well on your way to best practice in enterprise architecture. More importantly, the communication and organizational engagement issues will be solved. If you have hired correctly, the enterprise architect will also be an enthusiastic and invaluable member of the IT management and / or executive team.
As far as EA becoming more valued than ‘management’, I’m not sure when this will happen. But if we can stop whining about how difficult it is to get EA established and get on with the job (see above process) we at least won’t need to defend our failed efforts anymore.