Why Business Architecture and Enterprise Architecture Practices Often Fail

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.

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: Run 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. 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 for the architects who focused on building documents, pictures, and models. 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).