This post is the second one in our two-part series exploring how business architecture and IT architecture really are BFF (Best Friends Forever).
(P.S. Check out Part 1, if you missed it.)
And, we have a guest star. William Ulrich is President of TSG, Inc., Partner at Business Architecture Associates, and a Co-Founder of the Business Architecture Guild.®
Here in Post No. 15, Bill gives us the straight talk on how business architecture drives IT architecture alignment and transformation. This post is based on our recent interview with him. Disclaimer: we’ve made some tiny adjustments for our typical StraightTalk-style: the gray headings represent StraightTalk asking the questions and our guest, Bill, responds in turn. Make sure to check out StraightTalk podcast 5-Minutes With William Ulrich.
Let’s start with the big words. What does “business and IT architecture alignment” mean?
Bill: Business and IT architecture alignment represents a state in which IT application systems and data deployments fully enable business strategy, business capabilities, and stakeholder value delivery.
And what does “IT transformation” mean?
Bill: IT transformation is essentially the means of achieving business / IT architecture alignment. It could be small, like when an organization puts out a new product, or it could be large, like when an organization changes their entire business model.
BTW, here’s a really handy diagram from Bill that shows how business and IT architecture transformation works.
So how does business architecture help with both IT architecture alignment and transformation?
Bill: Business architecture provides a robust, unambiguous, non-redundant, ecosystem-wide frame of reference for the business and IT to leverage for understanding, transforming and generally achieving the stated business strategies. Business architecture removes the guesswork between business and IT. It lets the business refocus on setting and achieving business objectives, and it lets IT refocus on identifying scope and investing in IT architectures.
Now, how do we actually connect a business architecture to an IT architecture?
Bill: Once a business architecture is documented to a certain point, you can start to use it to align or “map” to the IT architecture. That starting position is generally represented as:
- Decomposition of capabilities down to level three
- Identification and articulation (a.k.a. detailed description) of externally-triggered and selected internally-triggered value streams
- A first cut information map to reflect the business capability / object relationships in the capability map
That establishes your baseline for understanding the business.
Bill: Then, because capabilities and information concepts are based on clearly defined, well-articulated, non-redundant business objects, you can start to use those capabilities to identify the automated systems that are either in place or that you need to start delivering value. Similarly, you can use the information map to identify the data impacts and data changes that may need to occur from a business-driven perspective. In fact, there are actually tools that you can use on the IT architecture side to identify some of this information at a more granular level.
But, the key thing is to use the capabilities as the lynchpin for connecting what the business does to how it is automated and where. Once you do that, you can connect those capabilities back to the value streams and they will show you which capabilities and which systems are delivering customer and other stakeholder value.
Is this a lot of work?
Bill: It’s as plain and simple as I stated, although it is a fairly large task in large IT architectures. All of these exercises are an investment in time, so IT mapping priorities should be driven by specific business transformation goals and business objectives, so that you can clearly control scope and focus on the best value back to the business.
Got it. Anything else?
Bill: Yes. IT really needs to stop trying to silo itself.
Tell us more.
Bill: IT in and of itself is not a standalone business, although there are movements in that direction. IT is another business unit that happens to own the role of automating IT architectures.
IT needs to be an integrated perspective. It shouldn’t think of the business as an internal set of customers; it should recognize the real business customers and the real business products that are delivered to those real business customers, just like the rest of the business does.
Siloing IT into a “business” and tricking itself into believing that the customers are really the business people and the products are what IT delivers back to them creates confusion—and it avoids and undercuts the ability to drive real value to the actual customers who are interested in acquiring the actual products.
Lastly, you know we love six-word memoirs. If business architecture were to have a six-word memoir to describe its relationship to IT architecture, what would it be?
Bill: Unambiguous business ecosystem frame of reference.