Now, you may be asking yourself, “I already have an Enterprise Architect on the team, isn’t that the same thing as a Business Architect?” The answer is a resounding, “Kinda…but not really!” An Enterprise Architect is the same thing as a Business Architect in the way that your CFO is the same thing as a Treasurer. Are they part of the same function? Yes. Could your CFO do the job? Probably. (And in some smaller companies that might even actually happen.) But given the complexity inherent in modern financial organizations, the CFO relies upon subject matter experts like the Treasurer to dive deep and execute expertly in their respective areas.
Such is the case with enterprise architecture since enterprise architecture is actually comprised of four domains; business architecture, data architecture, application architecture, and technology architecture. Now, just from looking at that list we see a clear focus on technology, which explains why Enterprise Architects are implemented in the way they are today and why a dedicated Business Architect is often absent in most organizations.
Look within your own organization and see where the Enterprise Architect sits. More than likely, they sit somewhere within IT, and even if they don’t, according to a CIO.com article, they are most likely to see IT management as their peers. Now, assuming the Enterprise Architect is fully engaged and empowered (which isn’t always the case), this can yield huge dividends by helping to ensure the IT organization has a “bi-lingual” business expert who can explain things to both IT and business stakeholders in a way they can each understand, therefore ensuring IT implementations are aligned with the business strategy. This is something that has become critical in an era of digital transformation where continuous technological evolution has resulted in nonstop change for the IT shop. But where does that leave business units when they need to evolve their business processes as part of a more holistic transformation? Enter the Business Architect.
According to studies from Bain, HBR, and McKinsey, only between 12% and 26% of transformations are successful, and that number drops to a mere 5% for digital transformations. What is the reason for such abysmal numbers? These studies concluded that one common theme surfaced across unsuccessful transformations: they were missing a solid thread from their vision, through their strategy, down to the execution of the initiatives responsible for carrying out the transformation.
Given the criticality of this thread from strategy to execution, who is responsible for it? Who is the person or team making sure all of the efforts of the organization, all of the investments of capital, across all the various business units are all aligned to the overarching objectives? Well, the Enterprise Architect usually does this for the IT shop specifically, but in most cases, in most business units…nobody. Of course, the CEO and their direct reports will set the strategy and the business unit leadership will execute against that, but where is the coordination when Company X’s Northeastern Snacks division implements an initiative to reengineer the order to cash process at the same time their Southwestern Beverage division roles out an initiative to upgrade the handheld units their route reps are using?
All too frequently, that coordination is lacking and there isn’t visibility into the duplicated spend. Inevitably, the two divisions (and IT) get confused and frustrated, and the initiatives fail, or are delayed, and money is wasted. It can be even worse when a major national customer of both divisions complains to them individually, but the company isn’t able to respond to the concerns in a unified manner. The company might then be looking at a loss of investment or of hard-won customers.
Since this hypothetical company is like most actual companies, the architecture discipline is relegated to the IT shop and only gets brought in towards the end of the effort to implement seamless supporting systems after the various business units have finally gotten all of their ducks in a row. Had they leveraged enterprise architecture via business architecture from the beginning, the Business Architect would have been that thread guiding them from strategy to execution. By creating business blueprints, like a business strategy or capability maps, the Business Architect can then leverage tools such as a Hoshin Kanri matrix or a Value Stream/Capability heat map to pinpoint where their company needs to invest in order to meet their strategic objectives.
Having done this, these hypothetical business units could have seamlessly transformed themselves, seamlessly supported themselves with enabling systems, and seamlessly realized the objectives of the strategy they set out to achieve. Market share would have doubled, and the stock price would have tripled. Well…maybe not quite, but the organization would have at least had the ability to ensure that the initiatives being executed on were orchestrated horizontally and vertically, that they were tied into supporting the overall business strategy (regardless of who was executing), and that all of the supporting capabilities were in place and able to support the changes before work even started.
Maintaining this holistic mindset is how we at Thought Ensemble are able to leverage business architecture best practices to help leaders transform their entire business, not just parts of it. If you leverage business architects in your enterprise or have thought about how you can better leverage this discipline in your transformation, I’d love to hear from you in the comments below!
