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.
The goals in many cases are pretty tactical in nature: they want to document their business processes, their way of doing business in a particular line of business; they want to streamline them; they want to automate them; they want to see if when they purchase a software package, can they just adopt that package, does it need to be tailored in some way, or do they need to change their processes to the workflows in the software package. That’s usually a big question for companies. In some cases, I’ve seen companies develop capability heat maps, capability roadmaps, and attempt to align the capability roadmaps to the value streams and to system development roadmaps.
I’ve spent most of my career in the government consulting space where the adoption of enterprise architecture practices was mandated by law, to the Clinger-Cohen Act of ’96, and through directives issued by the office of management and budget. As a result of those requirements, federal agencies stood up teams responsible for documenting the enterprise architecture for each agency or Bureau or department. And the private companies providing services to these agencies likewise started building their own enterprise architecture capabilities. Now, unfortunately like with many things that are mandated by law rather than through buy-in at the grassroots level, these offices have tended to exist in a silo, almost like an appendix to the IT organization rather than a true partner. Both to the business side, and to the IT side. And let me caveat by saying there are always some exceptions.
Now, on the private sector side, despite having some enterprise architects in-house, companies doing business with the government have tended to box in their own architects into some very specific and narrow roles. For example, they may be told “you work on contracts, you support our clients, but don’t worry about our own internal processes they’re just fine”. Or, they may be called an enterprise architect, but are just told to focus on system and technical architecture. Or, “you know how we do things here so we’re going to delegate you to support this Pega systems implementation or the Salesforce implementation”. So pretty tactical, pretty uni-dimensional roles.
These are all useful roles, obviously, but what’s missing here is that element where business architects provide the most value, in my opinion, which is helping develop the strategy and helping link the strategy to execution. What does that mean if you’re an organization or company and you don’t have the business architects to do that very critical function. It means that there’s an unspoken assumption that managers can take on Business Architecture responsibilities, even if they don’t have the training or the knowledge to do that. And for middle managers in particular who don’t have the budgets, don’t have the authority to hire external consultants, this poses a challenge because they’re supposed to focus on a fairly near-time planning horizon, they’re supposed to provide or to meet operational goals within the current quarter, half a year, or the current year. All this time operating in a very complex business environment with lots of moving parts with matrix organizations, with networks of interest and counter interests, and working with clients that have similarly complex organization. So, the managers have to be, and are forced to be, very tactical. And yet, at the same time, they’re expected to be strategic as well and be able to develop the growth strategy for their group and build the capabilities to support the growth strategy and meet the year after year growth requirements. When you think of it this way, it’s really no wonder that 50% of new businesses fail within five years, and 96% within 10 years.
I’m hoping that by saying this, I’m kind of putting a bug in people’s ears about the importance of hiring specialists to help with the Business Architecture.
GR: I appreciate that perspective very much. I think having some structure and knowing that there’s a methodology out there that they can apply to their organization, (because the Business Architecture has to obviously be customized to each organization), and having those tools and following that methodology will really help ensure the success of the organization and being able to meet their mission and objectives.
Editor’s Note: This is a five-part article and video series.
Watch the entire Top 5 Things to Know About Business Architecture video series
Read the other articles in the series here:
Article 1: What does Business Architecture Mean for You?
Article 3: What will Raise the Profile of the Business Architecture Discipline?
Article 4: When does Business Architecture Make a Difference?
Article 5: What does the Future Hold for Business Architecture?
