Gregg Rock interviews Ed Hunt in November 2021.

GR: How does business architecture improve business outcomes?

EH: That’s another very important question, Gregg. Business architecture doesn’t define strategy, but it is often a key enabler to enhance and extend it.

In addition to closing gaps in the requirements by using models and to improve communication, business architecture practices enhance and enable the strategy by maximizing the investment in technology. Sometimes that’s through establishing common services, understanding that these capabilities can be used and leveraged across the organization, but they also play a critical role in understanding how to apply the new technology in a way that’s specific to the operational complexity of this business, in a way that increases operational efficiency, and in a way that drives customer satisfaction.

GR: I wondering as practitioners, what do you think that we can do to help raise the profile of the Business Architecture discipline?

SL: Well, success in Business Architecture just like in any other discipline, is to a large extent, a matter of attitude. In my view, business architects need to approach every new client and every new assignment both with optimism and with curiosity. But, also with an understanding and an acceptance of the fact that they will have to provide a good dose of education as to what Business Architecture is, how it relates to IT, how it relates to strategic planning, and so on.

Gregg Rock interviews Ed Hunt in November 2021.

GR: The question I have for you is, why is business architecture so important to IT delivery?

EH: Well that is obviously an important question. Today’s businesses are a collection of independent, complex operations organized to provide value to the customer. And, each business entity is competing within the larger business ecosystem in order to offer a unique value proposition and then remain relevant to the market.

No longer are we just audit using technology to automate existing process document and automate existing processing, we’re using it to drive transformation. And, as I like to say the transformed organization, by definition, doesn’t exist.

We have to convert from de-scribing to pre-scribing, and that’s the critical role of the business architect.

GR: In your experience, do you find that organizations understand the value of Business Architecture, or is it a bit of a learning curve?

SL: The standard consulting response is that it depends. Some to, and some don’t. From what I’ve seen, organizations that are rich in workflows and in business roles, such as insurers, claims adjusters, lenders, transportation companies, they tend to have a greater appreciation for what Business Architecture can provide. Now, some of them start with a business reference architecture and tailor it to fit their way of doing business, others develop their own business process models usually, but not always, in a top down fashion.

GR: What do you think the future holds for Business Architecture and what do we have to do to stay in lockstep with the future needs of the organization and the advances we’re seeing in technology?

SL: In one of my articles published on the Business Architecture Institute’s website, I was making the case that the traditional methods that make up the standard Business Architecture canon, they tend to assume a slow changing, relatively predictable, business environment. A business environment where you don’t have major shocks to the system, major external or internal upheavals, essentially an environment that can wait for the business architect to do the architecting.

GR: What originally attracted you to the Business Architecture discipline, and what does Business Architecture mean for you?

SL: Well Gregg, to me gravitating towards Business Architecture has really been a natural evolution. My career started with an education in computer science, followed by a few years of software development, and from there I quickly realized that analyzing and distilling the customers requirements was a lot more interesting than coding the spec. And then, moreover, understanding the why behind the requirements, and that the needs that drove the requirements was even more interesting. Being able to correlate those needs with the customers business mission, business processes, supporting system, and data architecture while having that bird’s eye view of the whole texture of the organization was extremely compelling.