Us and Us: “The Business Architecture of IT”

Published

17 June 2019

Updated

10 August 2023

Learning Pathway

PRACTITIONER

Published In

USAGE
Summary
Once business architecture starts getting traction within an organization, there often comes a question: “Does IT have a business architecture?” This installment of StraightTalk explores this concept of “the business architecture of IT.”

Once business architecture starts getting traction within an organization, there often comes a question: “Does IT have a business architecture?”  This installment of StraightTalk explores this concept of “the business architecture of IT.”

Well, does it? Does IT have a business architecture?

Yes. The same one as the rest of the organization.

Explain.

If we are speaking of the IT department, from a business architecture perspective, it is a business unit just like any other one. A business unit that triggers and participates in value streams, that performs capabilities, and so forth — ultimately to the same end as all other business units, in support of the organization’s raison d’être.

What’s an example?

For example, the IT department performs capabilities related to managing IT strategy, plans, policies, research, agreements, vendors, team members, physical and technology assets, budgets, payments, programs, etc., etc., etc. All of these capabilities would already be captured within an organization’s capability map. (And, IT would have been at the table as one business unit to help develop that capability map.)

Of course, the IT department as a business unit (or sub-business units) could be cross-mapped to specific capabilities within the business architecture knowledgebase to make the relationship explicit — and then IT-specific capability views could be created.

The same is true for value streams, where IT stakeholders could trigger or participate in value streams such as Acquire Asset, Deploy Asset, Deliver Program, On-board Human Resource, Develop Human Resource Career, Disseminate Information, Conduct Audit, Ensure Compliance, Settle Account….

See the handy diagram below for a visual of that.

Diagram representing business architecture, organization and ecosystem

A Business Architecture Represents An Entire Organization And Its Ecosystem — Including Information Technology

Downloadable Media

Makes sense, but doesn’t IT have capabilities for customers and products as well?

No. In a business architecture, customers and products are always grounded in the bigger picture context of the entire organization. So, simply stated, a customer is an individual or entity which purchases or receives value from an organization’s products and services. A.k.a. the reason for the organization to exist. (See BIZBOK® Guide for official definitions of customer and product – we’re just StraightTalkin’ here.)

In the business architecture, a customer is never an internal definition (e.g., sometimes the IT department considers business partners to be “customers”). It doesn’t mean that we can’t think of delivering value to each other internally, but clarity of terms in business architecture is essential and if customer and product include all internal and external definitions of the words, we lose our entire common language and useful rationalized perspective.

What about the fact that technology enables entire organizations that couldn’t run without it?

Right on, and that’s a very important but different topic, technology enablement. From a business architecture perspective, this would be reflected in the business architecture and IT architecture alignment for an organization.

P.S. See Post No. 14 and Post No. 15 for more on business architecture and IT architecture alignment.

What about the fact that the lines between business and technology are blurring?

A relevant point, but still the same answer. An organization’s business architecture is what it is.

This blurring does, however, have significant implications on business models. It also means that as business architects we need to be educated in technology and current in our ways of working (e.g., with agile and co-creation mindsets).

I get it. So why do some people think this way?

There have been approaches (with the best of intentions) that have framed IT as running a business. This thinking, the idea that there should be a separate business architecture for the IT department, likely follows from those types of thought processes.

Anything else?

This is not about business and IT, or us and them. This is about us and us. We ARE us. One company, end of story.

As architects, we work tirelessly to bring business units together, so creating any additional divisions or frameworks to separate any part of the business from the others takes us in the wrong direction and increases complexity.

Perhaps we can leave behind business and IT — we’re already on our way to doing so — and simply move forward as value-delivering, technology-enabled organizations that make a difference to the lives of the people they serve and the people who work within them.

More Good Stuff…

BIZBOK® Guide (Business Architecture Guild®): Check out Part 6 of the BIZBOK® Guide on Business Architecture and IT Architecture alignment. (Business Architecture Guild® membership required.)

The StraightTalk on Business and IT Architecture Alignment: Check out the two-part StraightTalk blog series, BFF: Business Architecture + IT Architecture, Part 1 and Part 2, along with corresponding podcasts from industry gurus Mike Rosen and William Ulrich.

IT Isolationism: The Need to Reverse a Dangerous Countertrend (Blog Post by William Ulrich): A perspective on what happens when IT is viewed as a stand-alone business.

Us and Them: A Story We Can’t Help Telling (TED Talk): A fascinating TED Talk by David Berreby on some of the science behind our natural tendency to form us and them groups. These groups have value for our lives, he shares, but need to be handled properly.