Why Business Architecture and Enterprise Architecture Practices Often Fail

Abstract

When budgets tighten, Business Architecture and Enterprise Architecture practices are often some of the first organizations to get axed. This article helps understand why architecture practices are often the first to go and offers some best practices that can help justify the existence for architects.

The Thesis

Architecture practices fail when they’re disconnected from measurable business outcomes.

Understanding Why C-Levels Cut Architects in Tough Times

When budgets tighten, C-Level executives start hunting for low-hanging fruit that can get quickly cut from the tree. In plain speak, they look for roles that add the least amount of value for the money being spent on the people in those roles. And, while many architects are the first to jump up and state they add value, they rarely can clearly point to real money saved or money earned.

When leaders look at architecture organizations that are composed of Enterprise Architects, Business Architects, Solutions Architects, Data & Information Architects, Security Architects, Technology Architects and Application Architects, they’re usually looking for those roles that don’t get their hands dirty in real work (i.e., caring and feeding critical systems that keep the business running and making money).

This list of architects contains a mix of those who get their hands dirty and those who don’t. For those with significant architecture experience, you’ll know that Business Architects and Enterprise Architects are at the top of the chopping block because their outputs are often ‘paper’ (e.g., enterprise models, documentation, etc.).

The moral of this story is that if you’re an architect who is not coding or engineering real solutions that help save money or make money, or you’re a leader who has built organizations that fit such profiles, you and/or you’re organization at high risk for the chopping block when things next get tight.

The signs are simple and the patterns are easy to find:

• If you spend most of your time doing nothing but generating documentation (especially presentation-ware), you’re at risk.

• If you spend most of your time worrying about diagrams, you’re at risk.

• If you’re building enterprise models in tools that cost a great deal of money to own, operate and change but can’t tie it all to real money saved or real money earned, you’re at risk.

• If you spend most of your time in meetings instead of building, deploying, maintaining, and operating real systems that are critical to the business, you’re at risk.

The IF4IT Enterprise Architecture Value Model

The IF4IT has created an Enterprise Architecture Value Model (a.k.a. “the Architecture Value Ladder”) to help understand and foster an evolution towards greater value. It defines four separate levels of value that EA can bring to the enterprise, from lowest to highest. These levels are:

1. Review/Reviewing: At this level of value, EA sits outside of delivery and helps with technology assessments and opinions that hopefully will be used by other teams.

2. Advise/Advising: At this level of value, EA is providing enterprise policies, standards, best practices and guidelines that other should follow. They’re also providing some basic Solutions Architecture services that help other teams design their solutions.

3. Embed/Embedded: At this level of value, EA is embedded in initiatives and projects to help ensure the work has higher levels of success. At the low end of this value level, EA’s resources are embedded (often as Solutions Architects) to help design and vet solutions, including the decisions about what technology solutions to use, data and information, and more. At the high end of this value level, EA is taking on and running at-risk and high-risk projects to help ensure the highest levels of successful delivery.

4. Own/Owning: At this level value, EA owns and is responsible for its own IT portfolio of critical and horizontal IT assets that enable other critical vertical and horizontal IT portfolios.

Figure: The IF4IT Enterprise Architecture Value Model

Read more about the Enterprise Architecture Value Model.

Some things you can do to add greater value to your Enterprise Architecture practice include but are not limited to:

• Hiring Engineers as Architects (e.g., Coding Architects) so you can deliver solutions that are more than just architecture documents,

• Take ownership of cross-functional enterprise platforms and automations, so you can provide enterprise Software Engineering services, and

• Take on and run what are considered at-risk and high-risk work to become the elite team every IT C-level leader needs and depends on.

Best Practice: Hire Engineers as Architects (e.g., ‘Coding Architects’)

The simplest thing to do is to create architecture roles and organizations that add higher levels of measurable value. One way to do this is to hire highly technical people to be involved in the critical functions of building, deploying, maintaining, and operating systems and solutions that are critical to the business. At the heart of this is the reality that you need find, hire, develop, and maintain people with these types of skills. If you’re a leader who is not this type of technical, you’ll most likely build an organization that is very much like you, which is ‘non-technical.’ Know that this creates risk. The better option is to hire engineers, such software engineers, infrastructure engineers, and systems engineers who can understand complex systems and who can roll up their sleeves and get their hands dirty.

Best Practice: Engineer, Deliver and Manage Critical Horizontal Cross-Functional Platforms

Another way for architects to add more measurable value is to build (or buy), deliver, maintain, and operate critical cross-function platforms that are used by other critical business platforms. For example, if you build and maintain the underlying messaging platform that all critical business systems rely on, there’s a greater chance you’re in the middle of everything that is important to those business systems. If your federated software development teams rely on cross-functional enterprise software libraries that you build and maintain, there’s a greater chance you’re in the middle of everything that is important to most developers.

Best Practice: Take on and Run At-Risk and High-Risk Projects

One of the most powerful ways to add undoubted and measurable value (and gain great visibility throughout your enterprise) is to take on and lead the organization’s most complex and most at-risk projects. Architects who are technical enough to understand complex design and delivery, who can and are willing to take on high-risk projects, and who can manage the resources and budgets to do so are the types of ‘jump in’ resources every good C-level yearns for (and pays for). Turn yourself and/or your architecture organization into the types of people leaders turn to and you’re value and visibility will rapidly rise.

A global pharmaceutical company implemented this model in the 2008 timeframe. They turned their Solutions Architects into an elite team of technical project leaders who could jump in, triage at-risk projects, and deliver the solutions that other project managers struggled with. In doing so, their architecture organization and its architects quickly went from being virtually anonymous to being on demand throughout the global enterprise. The only downside was that these types of resources became targets for poaching from other teams and for the other architects who only focused on building documents, pictures, and models as almost no one knew who they were or what they did.

Conclusion

Architects who cannot be tied to real and regular cost savings or revenue generation are often some of the first resources to be let go when times get tough. If you want real value from your architecture organization, look to build an organization with the skills and reputation for getting its hands dirty. The dirtier, the better. Your C-level executives will thank you for it (instead of cutting you).