This blog post is a draft of something I’ve been working on. It’s not my typical “running, beer, and geeky things” type of post. However, it might give you a bit of insight as to what I do as a career right now, and how I think about things that I do at work. The picture associated with this post is of the new MN United FC stadium in the process of being built. It seemed appropriate for a post about architecture and strategy.
In the world of Enterprise Architecture (EA) there are many frameworks and paradigms that people look at to follow. Some of the most common ones break EA in to four component domains. These four domains are often referred to as:
- Business Architecture
- Data Architecture
- Technology Architecture
- Application Architecture
At first glance, one thing becomes apparent; namely that these domains seem to be focused on the world of Information Technology. In fact, Enterprise Architecture is often found under the IT department of many companies, reporting to the CIO. This leads to the misconception that EA is only applicable when talking about business objectives as they relate to Information Technology. I would posit that this could not be further from the truth.
At the core of Enterprise Architecture are three concepts; Vision, Strategy, and Knowledge. These three ideas encapsulate where you want to go (Vision), how you get there (Strategy), and what you have at your disposal to make it possible (Knowledge). These concepts are not exclusive to technology problems. Every business or organization wrestles with how to grow into the future.
The four domains of EA are simply a way to organize how we talk about problems that we’re trying to solve, and the strategy of new things that we’re trying to accomplish. Because of the growth of technology in all facets of almost every business, EA has been called upon to be the tool to manage how technology functions and grows. When we look at technology problems it’s easy to see how these traditional domains relate.
- Business architecture – This is how a business chooses which IT projects to embark upon, and how they match up to business goals. It’s a way to look at business capabilities and then map those capabilities to technology that achieves results.
- Data Architecture – Data management is a huge deal for many organizations. The skills of trained database administrators and data analysts are crucial to maintaining functioning databases and architecture of data that is used in technology solutions.
- Technology Architecture – When a business needs to deploy a technology solution it needs to have the right hardware and networks available to it to accomplish this. Often this means effective management of how technology and infrastructure is deployed. As well as deciding when, and when not, to try new things.
- Application Architecture – Finally, we get to the heart of many IT organizations, the application development and support teams. This domain seeks to effectively develop and deploy applications that carry out the business objectives of the organization.
Although this breakdown works well when talking about an Information Technology organization, I believe it can be taken further. This isn’t a new idea, as others have suggested this as well, but I would like to present a simple description of how I feel that these four domains can translate to any organizational situation, even outside of technology. To do that, I want to change the names a bit, but we’re going to start even further back. There are four key concepts that are required to run an effective organization.
- Why you do what you do
- What you know
- What you have
- How you accomplish work
Why you do what you do – Similar to traditional Business Architecture, this is about how you translate your business capabilities into effective goals and visions. A business/organization is pointless without a solid vision of what it’s about. You have to understand why you’re doing what you’re doing before you can begin to implement any type of solution. For some businesses this “why” might revolve around a shared vision of change in the world around them. For others, it may involve the skills and talents of specific individuals, and how they can use those skills to further the group’s goals. Whatever the driving force, the “why” will influence what you are capable of, and how you want to shape your mission.
What you know – Just like traditional data architecture, consideration needs to be given to your knowledge base. The information that is gathered in the collective of the organization forms the basis from which decisions and outcomes are driven. The intellectual property of an organization is often the gold mine of what makes that group unique. Almost every business, non-profit, or government entity, in existence has some level of proprietary knowledge. It knows something that others do not, and that knowledge is what sets itself apart from other organizations.
What you have – For many organizations, these are the assets and capital that have been invested in. Every business has “things” that they own. It might be their office equipment that help them do their job, or it might be their factory machines which produce their product. It could be a unique space or location where they do their business, or it could be a simple kitchen filled with pots and pans where amazing food is prepared. The assets of a business or organization are key to how they get their work done. However, these assets need to be managed effectively, and uniquely, depending on what they are. You manage a truck much differently than a computer server.
How you work – These are the business processes that are used to deliver the services or products of the organization. In the Information Technology world, this could be specialized applications that do unique functions for the consumer. In a bookstore, this would be how you manage your retail storefront with appropriate staffing and stocking of product. Development of these processes is key to effectively running a business. Without strong and effective processes, a business or organization cannot function to the best of its ability, and will not succeed. Managing these processes well is an art form and looks different in every situation.
If we start to look at Enterprise Architecture through this more holistic lens, we can see something that has more to say to an organization at large, and not just the Information Technology department. EA can provide a structure through which an entire organization can be viewed. By utilizing a structure such as has been laid out here, an organization can develop systems to manage each domain in the way that works best for each.
For a technology company that might mean traditional SDLC and data management practices. In the case of a manufacturing company it could include specific maintenance schedules and hardware refresh standards of critical equipment. Or, for a brewery it could mean management of the specialized knowledge of recipe creation and the catalog of recipes that the brewery has created. Therefore, I would propose a slightly different set of domains that encompass a bit broader view of what Enterprise Architecture can be.
- Business Architecture
- Knowledge Architecture
- Asset Architecture
- Process Architecture
When we’re open to looking at EA as something that goes beyond technology, then the frameworks can apply across a broad spectrum of industries and businesses. We don’t need to be limited to thinking of EA as just the domain of the CIO. We can bring it to the entire business, and apply solid principles of planning and management across everything that occurs. Enterprise Architects have a wonderful set of skills that can go beyond technology.
Architects are experts in helping develop processes for reviewing changes, or cataloging knowledge. They can look at the big picture view and help an organization manage their goals, both practically and strategically. Including solid Enterprise Architecture in an organization strengthens the organization as a whole, and can help drive progress to the future. It’s time to move beyond just EA for IT, and bring Architecture to the world at large.
Now that we’ve defined a different way to look at Enterprise Architecture we can start to talk about the different processes that can help guide an organization in each of these domains. That will be the topic of future entries.