The term Enterprise Architecture was first coined in the 1980s within a paper published by the National Institute of Standards and Technology. First well recognised framework was created by John Zachman called who had a background in the Systems Planning program of IBM.   The Zachman framework is on an ontology based on the principles of “What, How, When, Who, Where, and Why. It is the integration of answers to these questions that enables the comprehensive, composite description of complex ideas".

Enterprise Architecture is a practice typically found in larger, more complex organisations and is supported by a number of well-tested frameworks which guide can be developed.

The most commonly used and known framework is TOGAF developed by the Open Group, now in version 9.2. Additional frameworks include MODAF (now replaced by the NATO Architecture Framework), DoDAF and FEAF.

In practice, few frameworks are used in practiced “out of the box” but are customised to support specific organisation’s requirements or culture.

Enterprise Architecture is a planning approach which is used to understand the changes an organisation needs to go through to support future objectives. It includes both the business changes and supporting systems and IT changes required.

Very commonly there is an as-is (or current) view of the organisation which is then married up with a series of views of the future of the organisation (usually referred to as the Target Architecture) which defines the future organisation state from a systems and process viewpoint.

The Target Architecture creates a clear, well understood set of consistent viewpoints of the future organisation. In some instances, multiple Target Architectures could be created to test and discuss different future outcomes.

Within each architecture, there are multiple views or perspectives which show different roles the changes required in their domain. For example, there is normally a business perspective showing the processes, changes in value flow, products, services, etc. There would be a supporting applications perspective, a data perspective and so on which different stakeholders and teams can use to understand what needs to be built overt time and why.

It is also common practice to also include a series of interim architectural states which define major change states from the as-is architecture to the target architecture.

The changes towards the either the interim states or the final target architecture can be then delivered via change projects and programmes.

Enterprise Architecture is really about the process of understanding the current organisation and its problems that create barriers to change. The real value comes in when Architecture is then used to create models of the future organisation that can be shown to support both the leadership teams objectives and the strategies for how to achieve those objectives.

Architecture is as much about creating a concrete vision for the future and the meaningful and achievable steps to realise those outcomes.

It should set the scene for leadership teams to understand the path to realise the future they desire, and it should create a pragmatic map for delivery teams at all levels to understand the path that should be followed and the milestones along the way that deliver real business value.

When performed well, Enterprise Architecture is a powerful planning and governance tool that can create a powerful guiding framework for structure change which can enable iterative implementation within the context of a framework and guiding blueprint.

However, it is worth recognising that Enterprise Architecture as a practice has drawn some criticism in recent years, in some instances for good reason but sometimes this is due to the way Architecture functions are created, managed or led.

Here we will discuss some of the challenges we have seen with Enterprise Architecture and importantly, what you can do about them to create a high-performing function.

Over emphasis on the process, not the value.

In some organisations, particularly those that are new to Enterprise Architecture, there can be a tendency to overly focus on the process of performing Enterprise Architecture and slavish adherence to frameworks rather than the value and outcomes that architecture provides. For example, we have seen new architecture functions set up tight governance framework but with little focus on creating any target or interim states.

This results in bureaucratic management of delivery, slowing it down, without giving any guidance about the future direction to delivery teams about what to build and how to chunk up business value.

Lack of understanding of the discipline

One of the most significant barriers to enabling Enterprise Architecture to be effective is a general lack of understanding of what Enterprise Architecture is or is not by a variety of key stakeholders. As a result of this lack of understanding the people that manage Enterprise Architecture functions can sometimes fail to unleash the true potential of Enterprise Architecture.

Teams can get disillusioned and good architects (who are very often in high demand in the market) tend to leave quickly which further damages the reputation of the team.

Misplacing Enterprise Architecture in the organisation.

For Enterprise Architecture to be effective, in our experience, it needs to be placed within the right part of the organisation where it can facilitate an enable business led, strategic change. If placed too low, it can lack the oversight of strategic change required, lack the ability to interact with the right senior stakeholders or is solely focused on IT change.  If either of these happen, the value of Enterprise Architecture is significantly diminished. This is really a failure of leadership and understanding of Enterprise Architecture or an over willingness to control the EA function from IT leaders. To be effective, the function must be allowed to straddle and coordinate both business and IT change leaders. Equally, for this to happen, architects must be able to exhibit gravitas, strategic thinking and strong business understanding.

Lack of business experience or credibility

Effective Enterprise Architecture should be focussed on business outcomes and supporting business change first and then the systems required to change. Therefore, to be credible with the business, Enterprise Architects must be able to talk with the business stakeholders about challenges and potential future solutions and directions in support business strategy.

Architects must be sufficiently skilled and experienced in the business to be able to have productive conversations with business counterparts and to be taken credibly as partners driving positive change. Failure to have business facing conversations can lead to Enterprise Architects being pigeon-holed as ivory tower technologists and can be dismissed or side-lined by business colleagues. This is a dangerous place to be for Enterprise Architects and can result in an inability to influence or drive change at any meaningful level.

Too academic or overly focussed on tooling

One of the biggest challenges, which can lead to legitimate criticism of Enterprise Architects is a tendency to fixate on models, tools and some of the more esoteric and academic aspects of Enterprise Architecture (of which there are many). As a result, architects can be seen as fiddling with tools which other business users struggle to understand the importance of or the role of tools in supporting the change planning process. Good tools facilitate conversations but ultimately, collaboration is about humans working with humans to address strategic challenges.

Not data-driven

The final challenge in this list is as much about ways of working and credibility as about techniques related to Enterprise Architecture. In our experience, one of the most invaluable tools in an Enterprise Architect’s armoury is the ability to use data and insight about the business to drive productive conversations about how best to support future challenges. Without accurate and meaningful data about either the current state of the organisation and the challenges it faces or in the design of future state it can also create the perception that architects are disconnected from real understanding of what's really happening at the coalface of the organisation and can lead to the perception that enterprise architects are operating in an ivory tower. To counter this perception, it is important architects use the detail about the organisation grounded in reality and can work directly with implementation teams at a practical and meaningful level.

Given the challenges outlined above, we provide a few guiding principles when creating or managing an Enterprise Architecture team which should help you to overcome many of the risks of failure.

Enterprise Architecture from the outside might seem like a technical field but the most effective Enterprise Architecture teams in our experience are ones that build and maintain strong relationships with both business and IT stakeholders at a senior level.

To build strong senior relationships it is important enterprise architects can develop and nurture soft skills and good business understanding and empathy.

Because of this, some of the most effective architects we have ever employed and seen in client organisations are ones that started out in business facing roles where they have credibility and strong relationships already but have then moved into architectural functions where the systems and technical knowledge can be acquired or supported by more technical team members.

The most important, game-changing role for an Enterprise Architecture team is helping to build the detailed plans of the capability that the organisation needs to develop for the strategy to deliver.

The outcomes are a highly capable organisation and systems landscape that can be clearly shown to the support the strategy and outcomes the leadership are seeking. If a clear line between systems, organisation, capability and the roadmaps to achieve this can be drawn, the value of the Enterprise Architecture team becomes clear.

To be in a position to help enact the strategy, build lasting capability in the business and IT functions, it is vital that the function is appropriately placed in the organisation to interact with the accountable parties in these areas of the organisation.

They must be able to work as peers with the strategy development team, with the business leads and IT leaders in order to develop in each of these areas. For each organisation, this will be different, but we would caution against defaulting the Enterprise Architecture function low down where they will fail to build the right relationships.

As with all things in life, knowing what you want makes delivering it easier. If there is clarity about the role, outputs and value an Enterprise Architecture function is working to build, it is much easier to focus the team, the skills, relationships on that outcome.

As described above, we believe the role of Enterprise Architecture is to build and transform capability to support the strategy. It is not to run Enterprise Architecture governance processes without any clear view of the future of the organisation. Getting skilled, experienced people to run a process without knowing why is an exercise in futility.

Given the need for EA team members to have meaningful and value adding conversations with business counterparts we would recommend fast searching for enterprise architecture team members from the business divisions that they will be working with. Ideally searching first for people with good experience, relationships and credibility and who are adept and experienced at finding pragmatic solutions to problems and supporting strategic change.

If these people are willing to move into Enterprise Architecture functions, they can be cross trained with any technical skills required oh partnered with more technical team members as necessary.

Fundamentally, enterprise architects are there to find effective ways to build capability within the organisation to support the strategy. To find pragmatic solutions to complex problems, it's important for any decisions to be grounded in real insight and understanding. Enterprise Architecture functions are not there to spend their time making an inventory of systems or fiddling with tools.

To ensure Enterprise Architecture teams can be lean and strategic, we recommend using data driven tools to take on the heavy lifting of analysing systems and the complexity between systems. Architects can then spend their time using this data to drive insight and thinking about how existing systems and processes can be changed to best serve the strategy.

We hope you found this short guide to Enterprise Architecture useful. If you would like to discuss creation of an Enterprise Architecture function in your organisation, please contact us.