Manage Learn to apply best practices and optimize your operations.

William Ulrich on ''Business Architecture'' - Seeking a common language

Consistent vocabulary and view of the business can work wonders. Business architecture is discussed as road to app transformation in this Q&A.

We caught up last week with William Ulrich, head of TSG Inc., a long-time consultant concerned with IT issues. While integration and legacy modernization were our shared areas of interest, Ulrich clearly wanted to emphasize the wider goal of business transformation possible based on new approaches to business architecture.

Among other posts, Ulrich has served in recent years as co-chair of the OMG Architecture-Driven Modernization Task Force. He also co-chairs OMG's Business Architecture Special Interest Group and is co-founder of the Business Architecture Guild. Ulrich's recent books include ''Business Architecture: The Art and Practice of Business Transformation,'' written with Neal McWhorter. What were some of your intents in writing ''Business Architecture'':

William Ulrich: The purpose of the book was to give people a high-level overview of the topic including some key concepts – capability mapping, value stream mapping, organization mapping, etc., and to explain their use to the organization. The intent of the book was to make it very accessible to people without technical backgrounds because the business has to own and sponsor these concepts. So we wanted to make sure it was accessible to people that do not have an in depth IT or technical background. So it's an easy read. It explains the importance of business architecture and how to use it. It discusses how to use business architecture for business IT alignment, and is very specifically in terms of how you can drive transformation. The book features Leonardo da Vinci on the cover. Why is that?

Ulrich: Da Vinci was a polymath, which is what we feel the business architect should be. Not every business architect has to be the master of all trades and skills, but it helps to have a good working knowledge of all the different parts of the organization around you in terms of their roles and what their responsibilities are and so on. People have discussed business/IT alignment for years, and I wonder are there things that are new here that people should be aware of?

Ulrich: Yes. We have over the last two to three years evolved a fairly mature view of what constitutes a business from a business architecture perspective. Probably since the beginning of computing, IT would try to infer, or pull, views from crevices within the business. That is, either individual business units or groups or teams and so forth within the business. That's worked reasonably well over the years, as things have evolved. But now we’re beginning to realize that we have many, many systems and we have a high degree of redundancy and inconsistency between systems.

And we're not recognizing our customers in all cases. Moreover we're treating our customers in a different way depending on what way they come into the business – what product line they start on and what part of the business they're dealing with.

We're realizing that we need a more common view. The old way of doing this, where IT would extract it one tooth at a time from the business group, while the business side is saying we don't have the time for this, [leads to ] collecting many conflicting views from many different sources - then IT is left to sort that out. That's just not working anymore. And if you want a crystal clear example, go to any team that's putting together an enterprise data warehouse and ask them how well they're doing at aligning all the information that's being filtered to them from all these siloed, redundant operational environments that are out there. They will tell you that they wrestle every day with figuring out if this widget is really a widget.  They ask, 'Do these numbers align?' - it doesn't quite make sense. 'How many spreadsheets do we need to massage it into [the right form]?' It's rampant.

They are trying to shift to a customer-centric view of the business. That is, externally focused, not internally focused. Not regionally, but internationally focused. When you try to do that without a common language across business units, you're going to land on your face every time.

As much as IT can say "we have the tools and techniques to draw that out," they won't be successful if they're trying to draw it out from several pockets, so what they really need is a clear concise vocabulary and that's what the business architecture provides – both consistent and complementary views of the business.

So you've got what the business does in business capabilities, you’ve got how stake holder value is achieved in value streams and other types of value maps, you've got information views and definitions for common vocabulary, and you have an organizational map that sort of sits on top of all that.

When you have a consistent view of the business and a consistent vocabulary, that's when you can start working wonders. The data architects are the first to receive the value from that, but the solution architects can start to really dig in and see now that they have a business view of what's going – then they don't have to try to abstract a bunch of complicated pictures and diagrams that don't really connect.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.