Many organizations today have some level of enterprise architecture responsibility, whether as a role, an office, or a committee. This responsibility focuses on making sure the business’s technology decisions fit into the overall architecture of the entire enterprise, not just a department or product line.

Enterprise architects are the big-picture, interoperability, long-term lifecycle people.

They’re making sure what you want to buy plays well with what you already own and you know what you’re going to do with the shiny new thing when you’re done with it. Enterprise architecture is an essential part of managing the modern world of enterprise technology.

Enterprise Architecture Was Never Just About Technology

Not too long ago, enterprise architects weren’t in the technology space. We’ve added the silent word “technology” to the title “enterprise technology architect.”

With data architects, software architects, integration architects, and more all working together on enterprise technology platforms, we decided to wave our hand and shorten it all to “enterprise architecture.” This shift made even more sense as technology became a pervasive part of every corner of every business.

All companies today are technology companies.

Naturally, they need to have an enterprise architecture plan to address how it all works together.

The shift to “enterprise technology architect” came at a cost, though. We now have fewer people playing the original role of enterprise architect. What did those architects do before there was information technology at every corner?

They “architected” the “enterprise.” (Enterprise architecture) The enterprise is, of course, the business. The architecture is how that business is structured and how it communicates within itself.

Before enterprise technology, information within the business still flowed between team members and departments. Who was in the loop on receiving the information and deciding what to do was just as important as our modern data flow diagrams between systems.

Who’s in Charge of What?

We can see the importance of an enterprise architect when we think of the ongoing struggle of how to organize our IT functions. Do you have a Chief Technology Officer, Chief Information Officer, Chief Data Officer, Chief Product Officer, Chief Information Security Officer, and now even a Chief AI Officer?

If so, your organization surely has figured out the lines of demarcation between each role.

Overlapping responsibilities are hopefully defined and decided in the organizational charter for each group. And the reporting lines are figured out as well.

Does the CPO report to the CTO? What about the CISO? To the CTO, CIO, or maybe the CEO?

All of these decisions impact how information flows through the organization and how the business reacts to, adapts to, and decides on how to operate.

Organizational Design Is Information Architecture

When the organization of the business drives how efficiently and effectively the business operates – you’ve got enterprise architecture.

Now the question is who did the architecting?

In many companies, the architecture is based on the personalities of the leaders. How good are they at advocating for their corner of the kingdom and who should be above and below them in the org chart? Sometimes this approach produces good design – and often it does not. Instead, an enterprise architect, trained and experienced in good enterprise design, can help see past personalities and focus on the functions.

Organizational enterprise architecture isn’t significantly different than technology enterprise architecture. Both are concerned with information and how it moves within the business.

Just as an IT system, such as a Customer Relationship Management product, has inputs, outputs, and processes it performs, and so do the departments of an organization. Every department provides a function to the business. To serve the function, the people within it require information – from customers, from outside, or from other departments. Once they receive it, they do their jobs and then provide an output.

Thinking about departments as information processors helps discover the parallels between thinking organizational versus thinking technological.

For example, what are the inputs and outputs of the office of the CTO?

Assuming their charter is to build and manage the technology which produces the company’s revenue, then the inputs come from the market, customers, and product leadership. What market problems are you trying to solve? What new features enable the company’s goals? Where are there friction points or customer success issues? These are all examples of the input into the technology team.

Those inputs then go through all the processes the teams perform. Software development, research, usability testing, quality assurance, and more all live in the inside of this business function.

And the output? Following our assumption above it is the technology product serving the clients.

There are other parallel questions to consider as well. What constraints exist on the department? What other groups do they interact with the most? The answer of course depends on the company and the industry. Just as no enterprise technology is the best for all situations, the organization design is custom as well. You have to find the right fit for the unique challenges your business faces.

Should the CISO report to the CEO or somewhere else? Are you a public company or highly regulated? If so, your answer will be different than companies who are not. Is your Product team part of your Technology team? If you’re a Software as a Service (SaaS) company, almost certainly yes. An agricultural manufacturer? Maybe not.

Following the Information

The enterprise architecture extends beyond these technology teams as well.

Risk, legal, human resources, sales, marketing, and beyond are all part of the overall architecture. A good review of it may even find corners of the business effectively cut off from the main operations. Either they’re not receiving key information to do their job or their output is lost on a shelf and ignored by decision makers. An enterprise architect can help find these issues and let you decide how to fix it.

New lines of communication, integrating departments, or even cutting portions loose – all are on the table when it comes to rearchitecting what’s needed to build a stronger business.

If the original enterprise architect was “architecting the enterprise,” how did we shift to this new world where their focus is technology instead of org charts? The simple answer is they followed the information.

As company information moved from file and mail rooms to file and email servers, the need for good architecture moved as well. The organization of the enterprise still matters, but bad enterprise technology decisions typically have higher costs and fail faster.

The priority became making good technology decisions.

Enterprise technology architects became the domain experts. In some companies, organization design still occurred too – in others, this fell back to the executive team.

Stop Copying the Org Chart Next Door

It’s important to understand both types of enterprise architecture. The technology takeover of companies did not replace the need to consider organizational design. It did add new complexities in how to operate a business, justifying the need for our enterprise technology architecture efforts.

But organizational design still matters.

Too often companies design their organization to match where the leaders were before or just base them on trends within the industry. You can lean on numerous industry reports about technology products to find the best fit for your company. But finding the same for organizational structure is more difficult and often relegated to academic work or expensive business consulting (who are following the same academic or institutional guidance).

These rarely will give leadership the encouragement and support to try something unique for their business and counter the conventional wisdom.

The Wrap

What should a company do if they think their organization’s design may not be best for how they operate? Hiring traditional enterprise architects or business management consultants is one approach. But you’ll pay for the ramp up time for them to understand your industry and your unique business needs.

Alternatively, leveraging your existing leadership and technology architects can jumpstart the process.

Treating the organization as a data processing system will likely come naturally to your technologists. And your leaders should be able to define the business goals and pain points which need to be addressed. Creating a shared mission and defined responsibilities can allow you to create your own “enterprise architecture” working group to help plan out what’s right for you.

The end goal is to make sure you have the right structure to deliver the results your business needs.

The current structure of many businesses is based on assumptions. The assumptions may have come from the past or from other organizations and many of them may not even apply to the organization today. Enterprise architecture gives you a model to challenge the assumptions and make sure your organizational design meets the challenges of today and enables the opportunities of tomorrow.

At that point, you truly are architecting your enterprise, not just your enterprise technology.