Six Signs That You Should Revisit Your Enterprise Architecture Strategy

Enterprise Architecture is an often overlooked and even more often misunderstood aspect of our organizations. It's unfortunate that many view the role of Enterprise Architecture to be not much more than an expanded version of solutions architecture. Solutions architecture is actually just one portion of the much broader domain. The larger domain of Enterprise Architecture is intended to drive cohesion between customer needs and the technical solutions. In order to create that cohesion, its focus starts much earlier in the process. It starts in the definition of what solutions will be developed and not just how. It may be that your organization does not have and Enterprise Architecture practice or it may be that its effectiveness has not been reviewed in a while. In either case, I thought it might be helpful to have a quick way of determining whether your practice should be reviewed. Here are some key symptoms to help you recognize when your Enterprise Architecture approach may need to be refreshed.

1. Unknown or poorly defined business drivers - if it's difficult to tell what challenge your technology solutions are addressing, then you may have a disconnect in the early stages of your architecture cycle. One example of this is when we start defining features that we think we need but are unable to clearly explain how they provide value to our customers.

2. Well defined business goals but an inability identify potential solutions - if you are finding it difficult to find potential solutions or find yourself settling on the first approach identified, your capabilities in the Enterprise Architecture domain may need to be upgraded. Our solutions will typically be stronger if we can identify multiple approaches and select the best one out of many. We can uncover surprising insight when we can articulate why we are not choosing a particular path.

3. Well defined solutions but an inability to implement them - if you know what you need but can't seem to get the solution implemented it may mean that your technology capabilities have not been matched with your organization's strategy.

4. Implementations that don't match your designs - sometimes this does not indicate a problem. If the differences come about through a process and are understood to solve the given challenge better than the original design, then the process is working. However, if the differences are surprises at the end of the implementation or create gaps in functionality then they may be symptoms of poor implementation controls and lack of communication

5. Well executed implementations that meet the technical specifications but still don't deliver the desired customer value - this can be caused by a breakdown in multiple areas. It could come from poor initial understanding of the business challenge, or it could come from a misunderstanding of how the technology can solve for the given problem

6. Chronic challenges in delivering value - all organizations will encounter challenges in their delivery but if you keep fighting the same ones on every implementation then you may not be closing the loop in your architecture cycle. By incorporating feedback into your architecture process, over time your solutions will better fit customers' needs, and the implementations will run more smoothly.

Often, these challenges are identified as issues belonging to a subcomponent of the broader cycle, but we tend to miss opportunities or even fail to correct the issues when we address them in a silo. For instance, it would be very easy to experience symptom number 5 above and arrive at a very ineffective solution for it. An initial review of the situation may lead us to think that the implementation team performed very well but the sponsor's team simply asked for a silly feature. So what's the solution in that case? Just stop asking for silly features?

The solution is to look at the architecture cycle in broader terms to identify the many areas that may have influenced the outcome. One such area could be that the technology team wasn't brought into the conversation early enough and more effective solutions simply were not considered. Another real possibility would be that the implementation team didn't design their iterations with a feedback loop that would have allowed them to understand the flaws early and then pivot during the development phase.

There are, of course other possibilities but the point is that Enterprise Architecture is much more than technology. Symptoms of flawed Enterprise Architecture can show up in many points in the delivery cycle. If we truly understand the role of these architects and periodically review our processes, we can remove a wide array of inefficiencies and failures from our delivery pipeline. If there is a breakdown between the conceptualization and final delivery, there is a good chance that a solid Enterprise Integration program could help.