We often hear people say that an Enterprise Architecture Team needs to be engaged with the business to be successful. We agree that business engagement is the best way for EA teams to deliver business value, but it’s not the only way.
Enterprise Architecture teams in start-up mode, or that have low maturity, often have little to no engagement with business teams, but they can still deliver value by addressing problems in IT. In fact, we’d argue that this is probably the best way for a low maturity team to start anyway. If we think about stakeholders, then a CIO or a Head of Digital is usually the person to whom such an architecture team reports. Their first challenge is to make that person happy: address their burning issues, help them do their job better, and then build on that. Importantly, value to the business can be something that doesn’t involve the business teams directly: for example, a reduction in IT cost by using cloud services is a positive business outcome. Typically, active engagement with business teams will only begin to build when the EA team can demonstrate value that impacts them directly.
Here’s an example of how a novice EA team in a global Financial Services business took a staged approach to deliver value, and how business team engagement eventually came about through a natural process.
The EA team were low maturity and lacked focus. They felt that their CIO didn’t really engage or value them and that their lack of working with business teams was a problem, as they felt they couldn’t add real value. A newly appointed chief architect spoke to the global CIO who stated that one of his major concerns, which was pretty basic but not uncommon, was that he didn’t have a coherent view of applications globally, and this constrained his ability to know where he could rationalise.
Asking the CIO what problem he wanted solving quickly narrowed down the scope and gave the EA team a focus for their work. The team took six weeks to assemble the company’s application portfolio by interviewing the global IT teams, categorising the applications, and compiling a list of all the applications IT were aware of. The result was a catalogue of applications, showing which business units used those applications. In the end the team had a CIO who was pleased to finally have visibility of his application portfolio (including a lot more applications than he thought he had). This may not seem very exciting, but moving from nothing to something bought the team credibility, personal interest from the CIO, and delivery of some value to the business by exposing information that could be used in directing effort for initiatives (in this case identifying where there were potential opportunities for rationalisation).
Once the EA team had internal credibility, it was able to build on that, so the team’s next area of focus involved working with the IT financial controller to define a template for application costs and to identify those costs globally, and also liaising with IT Procurement to capture relevant vendor license dates. All the required information was available within the IT organisation. With the CIO now fully engaged, the global IT teams provided the necessary information. The EA team then linked the information gathered to the applications and a view as to where the costs were in the application architecture. Now the CIO had visibility of application costs globally, mapped to application categories and business units. He could see that one business area had high costs and what appeared to be duplicate systems, and this indicated where more concrete opportunities for rationalisation existed. It allowed him to engage with the COO of the business unit to discuss the potential opportunities. The EA team had delivered more value, as they had uncovered insights of interest to a key business leader. Three months in, and the EA team had still not engaged directly with the business teams but were delivering business value, the CIO was very pleased, and a COO was aware of the output and interested.
The next stage was when the EA team began to get business engagement. The business unit COO was now wanted to understand exactly what these costs were and whether they could be reduced. To answer this, the EAs needed to gain a detailed appreciation of what the applications did, so had to work with the business teams that used the applications to understand which processes and products they used, and how they supported the business. They mapped out the opportunities, the potential implementation costs and costs savings, and how the systems could be rationalised. Having presented this to the COO, a programme of work was launched to implement the changes, and again a business outcome resulted – cost reduction was delivered.
Interestingly, the work with the financial controller had been noticed by the Finance team who asked the EA team to review the Finance applications portfolio and recommend how it could be made more efficient.
The message here is that if you don’t have business team engagement for enterprise architecture, don’t worry, as you can gain that over time by delivering value, initially to your direct stakeholders (your boss or you boss’s boss). Delivering good ‘stuff’ often leads to interest from other parties and further engagement. The key thing is not to try to do too much too soon. It’s all very well talking about strategy, roadmaps, standards, design authorities, etc., but without any engagement then it will typically lead to nothing. It could take 3 months, 6 months or longer before you can engage business teams, but you should see this as a multi-stage journey, gain credibility and grow your team maturity. The really interesting stuff will come later, just don’t rush it.
PS if you’ve seen the Essential Playbook, the example here was an influence on Play 1 and a lot of the functionality in the Business Capability Dashboard was developed based on learning from this.