In any organisation, enterprise architecture should be established as a core competence. However, we observe that even in organisations that have had an EA function in place for many years, only recently has enterprise architecture gained any real traction with the business change and systems delivery project teams. Often, only through bitter experience has the value of the function been appreciated (for example, after it has resolved conflicts between projects). Successful enterprise architecture teams have strong backing from the CIO and the CTO, and are seen to guide and support, rather than simply police, the design activities of change projects.
In large, complex organisations we typically find the enterprise architecture function split between a central infrastructure support group that assumes responsibility for technology architecture, and a business-facing side of the IT organization that handles business, information and application architectures. Multidivisional companies – particularly those with a global reach – provide a further layer of complexity, with certain enterprise architecture responsibilities handled at a business unit level and others managed at a corporate level (predominantly group-wide standards and business/IT architectures covering shared functions such as Finance or HR). The need here is to ensure alignment of the architectures and architects across the organization, and this places significant demands on the governance mechanisms.
Many of our clients report tensions between the central enterprise architecture team and the solution architects or designers assigned to projects. While the enterprise architects are intent on assuring the integrity of the target business operating model and its IT support, project managers and their designers are motivated by the need to deliver restricted solutions in line with their agreed project budgets and schedules. When these interests conflict, as they inevitably will, the project managers often win the day. This is because change projects can generally draw upon strong business support, while enterprise architects are seen as serving a worthy but remote and less tangible cause. The predictable consequence is an unplanned proliferation of incompatible solutions. See our previous article on this tension and the need to be seen as a trusted advisor.
We believe that ensuring successful alignment between enterprise architecture and change projects requires the following:
- Provide strong, but effective governance mechanisms – ensure they are usable by the teams that are implementing change, that they are not onerous and make them self-service if you can (see previous blog).
- Ensure continuous executive-level support for enterprise architecture – deliver outputs that the executives can use in their decision making, note that they want high-level information that conveys some interesting insight, not a plethora of wiring diagrams.
- Keep the enterprise architecture information up-to-date – ensure you have processes in place to keep the information current. Whether you are using Excel or an EA tool like Essential, if people are using that data to make decisions, they need to trust it is correct. Stale data is the death of any EA initiative, once people lose trust they stop engaging. If you use an EA tool we recommend that you make data maintenance a step in the change process, and our constant message is to only ask people to capture what is:
a) not onerous to capture for them
b) enough to ensure the data is of use as part of the EA process
c) is clearly of use to them in their jobs or, if not of use to them in their immediate role is only a few moments of additional work – don’t add in lots of additional items just because they may be useful in the future. - Build enterprise architecture into the change management process – linked to the point above, if you can make EA maintenance a step in the change process then it is much easier to manage; if it is inherent in what people do then it doesn’t appear to be additional add-on work. Work with the PMO or change management teams on this, and keep in mind the previous bullet.
- Ensure the enterprise architects work actively with the project teams – see our blog on being a trusted advisor, but note that this is about helping the project teams deliver on-time (or quicker) and effectively. It may be small inputs initially, but our experience tells us that over time, as the EA input shows value they will want to engage more and more.
- Establish processes for non-conformance – you have to tread carefully with this one and engage the CIO in it from the start. You need to be able to demonstrate examples of success in teams that are following the enterprise architecture process. Initially, take a softly, softly approach as people start to understand the process and learn how it works, and as the EA team builds relationships, but you will undoubtedly find people who will just not engage at all. Bring them to a Design Authority meeting, invite the CIO and ask them to explain their reasoning. Typically, teams don’t like being exposed in front of the boss.
Delivering a successful enterprise architecture is not hard, it just takes a little work