Do we really understand what the problem is? (Part 2)
The concept of Enterprise Architecture is a sound one. Having a framework and skillsets which can help inform technology decisions, to reduce complexity, duplication and technical debt while ensuring an alignment to business strategy – what’s not to like! In most cases, Enterprise Architecture (EA) teams emerged from IT divisions to provide technology leadership and assist in setting the strategic direction for an organisations technology investments. They are (or should be) the keeper and reiterator of the technology vision however, in recent times these groups seem to have fallen out of favour.
As organisations focus on Program/Project management (see ‘Do we really understand what the problem is? (Part 1)’), Enterprise Architecture teams have been downsized and/or staffed with less experienced staff (as a cost reduction exercise). With inexperienced staff comes an inability to influence and little or no authority to stop high profile projects from making architecture calls. The EA group is also typically painted with the IT brush therefore struggle to gain any credibility with business stakeholders.
It hasn't helped that the focus of EA groups has also changed over the years, swinging around from trying to do everything from documenting the current IT estates to developing technology roadmaps and target states, from solution design to developing white papers on the latest technology trends. Most have also tried implementing some sort of EA framework so they can get others to understand what they actually do but this usually ends with mixed results. Most of these frameworks are more academic than practical so they are becoming extraneous in today’s fast moving business world.
With the technology landscape changing quickly, business areas are getting impatient for change and with limited resources to undertake the work, the EA groups are struggling to meet expectations. Indeed their relevance is being questioned in some circles. The group haven’t helped themselves either by producing artifacts, patterns and new processes that are less than useful for projects to consume. In other words, EA groups have failed to understand their customer needs.
Lacking creditability, what is starting to happen in a number of organisations is that projects are bypassing EA and implementing technologies that are further complicating the already complicated IT eco-system and steadily adding to the current technical debt. It might only seem like a small thing on the surface, a project making a tactical decision to get the development team to build a required feature rather than leverage an existing function or buying something from the marketplace which is pre-built. The usual argument you hear from the project is that if they have to buy something new it will put pressure of the project timeline due to the procurement overheads. The bottom line is that it’s easier to task a developer to quickly whip something up.
If the project gets its way, the end result is more duplication and/or bespoke code which, needs to be managed, updated and maintained for the life of the system. In most cases, the justification for the decision is not quantified and not escalated back to the Program Board (and, in some cases, not even to the Project Board). It is not deemed as holding enough importance to warrant decision making at such a level. In the end, the PM ends up makes the call based on project risk and not total cost of ownership for the organisation and the technical debt is banked requiring to be paid off down the track. The under-the-pump CIO doesn’t seem too concerned as they are just relieved that the project was delivered on-time and on-budget (therefore deemed as a success) so they can keep their jobs until the next IT related stuff up. The technical debt can be paid off later.
Just like the investment in Project/Program management offices, an EA practice needs investment in skilled (not in just technical but people skills as well), motivated, pragmatic and business focused staff. It also needs agreed measures to demonstrate that the investment in the group is making a difference. These could be around a reduction in technical debt, or the number of reused corporate assets in solutions designs, or how many systems where designed using existing patterns. A measure of business improvement also needs to be included as EA should be more holistic than just IT.
Investment in EA governance also needs focus and needs to be incorporated in the Program/Project management processes to ensure that the technical solutions abide by the architectural principles defined and approved by the EA Board. An active EA Board is critical in quality outcomes and should work hand-in-glove with the Program and Project methodologies and governance models. An Enterprise Architect should be embedded in Project teams for the life of the project and your senior EA should be a standing member of the Program Board. Most importantly the Enterprise Architect needs the authority to make judgment calls in an environment that is well supported by an appropriate organisational governance model.
Project Managers who are found to have made technical decisions need to be held to account or the poor practices will continue. With effective leadership at an Executive level that can follow through on stamping out poor practices, it doesn’t take very long to see results.
At the end of the day, it’s important to remember to keep the eye on what the organisational problem is you are trying to solve. It’s too easy to fall into the trap of setting up new processes and committees and forgetting why you are actually doing it.
Recently I was invited to an EA Board meeting of one of my customers. The Chair started the meeting by outlining the role and charter of her Committee then outlined why it was set up in the first place. This really helped focus the discussion and is an approach I would recommend you place inside your kit bag for future re-use.
Enterprise Architecture can be a key enabler for any organisation as long as it has a clear focus of what problem(s) they are trying to solve – they can’t solve world peace! As each organisation has a slightly different set of problems and levels of maturity, it’s not possible to recommend a single approach for your situation. This is why it is so important to list and prioritise your problems so you can focus your precious resources. Undertaking such an exercise can be challenging as there can be so many issues that need attention but with some professional facilitation some good results can be achieved.
