Enterprise Architecture beyond technology

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.


Practical Enterprise Architecture, pt 3

The next stop on our tour of Enterprise Architecture takes us into the world of Data Architecture. Data Architecture is the component of EA that speaks to the vast pool of knowledge that any organization needs to manage. Every organization uses data, and therefore, every organization can benefit from good data architecture.

One of the big players in the data architecture space is DAMA International, a group that if focused on presenting their Data Management Body of Knowledge (DMBOK) on data architecture to the world. This DMBOK focuses on the data architecture wheel pictured below.


This wheel highlights all of the different areas that data architecture is focused on. Although much of this seems highly technical, and aimed at database professionals, there is a lot here that we can take away on a simplified level.

One of the big keys to understanding your data is actually speaking the same language when talking about it. The idea of meta data management addresses this by encouraging you to understand the data that describes your data. In simpler terms, it’s not enough to just store a lot of data, but you also need to understand what that data means, and why it is important. Many times it can be tempting to just store as much information as possible, but without much understanding of it’s meaning. It’s more important to understand what you’re collecting, and why, than it is to collect a lot of it.

Data architecture is also concerned with how data is stored and accessed. How frustrating is it when you’re trying to find something, and can’t. This was the reason for the invention of systems like the library card catalog, which helps manage large amounts on information in an easily accessible way. Data architecture seeks to bring that same rigor to any type of data.

Let’s go back to our cafe example. You might think that there isn’t much in the way of data that a cafe would need to maintain. However, even a business like that has lots on information that it collects, and should have a plan for managing. First, there is the actual data regarding business operations, such as recipes and inventory of materials/ingredients. How this proprietary information is stored and made available is key to how quickly the business can hire new people, or change products.

Apart from actual operations, there is the management of all of your customer data. You want to know who is coming into your cafe, and how you can get them to come back again and again. This type of marketing data is often filled with great data points that can help build the business, but it needs to be managed in a way that makes the data useful. Data architecture helps define this to help the business reach it’s goals.

Data architecture is one of the oldest disciplines of Enterprise Architecture, and it’s one of the most important. Managing your data is key to supporting all of the other domains, and helping them bring the organization into the future.


Practical Enterprise Architecture, pt 2

In our first installment of looking at Enterprise Architecture, we looked at the foundation of what I am calling the house of EA. This foundation is focused on vision, strategy, and knowledge, as a basis for how all of Enterprise Architecture is built. As we move up into the pillars of the house, we move into what are called the four ‘domains’ of architecture. The four domains are the areas where the work of EA happens.


The first of these domains is Business Architecture. Business architecture is concerned with what makes the business tick. It asks the tough questions about how business goals can be met utilizing the tools that are available. BA is the area of architecture that is most concerned with how the vision of the business meets the practical needs and capabilities of the organization.

It’s important to note, that just because the word ‘business’ is in the title, it doesn’t mean that this area of architecture is limited to corporations. Every organization can benefit from looking at how they “do business”. The term ‘business’ is more about the actions of the organization, not a definition of what type it may or may not be.

Some of the work that happens in the business architecture domain revolves around the capabilities of a business. One of the key elements about moving a vision forward, is having the knowledge of what you’re capable of, at the current time. Business architecture helps an organization look at it’s capabilities, and then aligns those capabilities with the vision of where the organization wants to go. Then once you understand the current state, you can start to examine a path to move forward. This also helps identify gaps that need to be fixed before change can happen.

Sometimes this can sound very corporate and structured. However, if we look at our fictional cafe from the first part of this series, we can see how business architecture would apply in a very real way, despite not being a big corporation. In our first part we identified a cafe that has a stated vision of being a central place of community within a neighborhood. Business architecture would then examine the capabilities of the cafe, and how those align with the vision of where it would want to be in the future.

This means first identifying everything that the cafe has at it’s disposal to build itself up. Perhaps there is space that is not being utilized as best as it could, or perhaps there are improvements to how the marketing of the cafe is being done. These types of outcomes result from a solid understanding of how the business is architected. Once this understanding is complete, then plans could be put in place for how to make changes.

Let’s say that there is space in the cafe that isn’t being utilized the best that it could be; perhaps it’s closed off from the main area, and doesn’t feel as connected to the primary space. Business architecture would ask how this capability deficit could be turned into a benefit for the business. If the stated vision of ‘community’ is driving the analysis, then perhaps showing how this space could be used as a private meeting area for community groups would be a benefit to the cafe, turning something that wasn’t useful before into something that helps drive the overall vision of the organization.

Business architecture would be the domain of EA that would be looking at these opportunities and presenting them to the ownership of the business as potential ways to meet the vision of the organization. In a formal corporate structure this involves the development of capability models, impact analysis, gap analysis, goal to outcome mappings, and other various artifacts. Yet, I feel that the basics of what business architecture is trying to accomplish can be done on any scale. It just comes down to being willing to do a through analysis of how business is being done, and use that analysis to plan for the future.

Business architecture is a key element of of EA gets done. Many big organizations see business architecture as a small part of EA, but it is really one of the most crucial. It’s very easy to want to skip over doing all of the business analysis and jump right in to how to solve problems, but if you don’t understand the foundation of what you’re dealing with, you can’t plan for the future in the best way possible. Good planning helps to avoid pitfalls of jumping too fast, and makes an organization stronger and more capable of achieving what they want to become.

Practical Enterprise Architecture, pt. 1

For a part of my career I’ve been an Enterprise Architect. Many times when I mention that job title to people, they have no idea what it’s really about. Therefore, I’m going to start a multipart series on this blog to talk about what Enterprise Architecture is, and present a simplified, and practical, methodology that I adhere to from my years in the industry. Even though I’m currently a direct manager, I still try to infuse Enterprise Architectural practices into my work, and as I’ll talk about towards the end of this series, Enterprise Architecture can actually be used as a model for talking about life planning and management as well.

To begin, the discipline of Enterprise Architecture is simply defined as a series of processes, practices, and guidelines that help guide decision making, and manage a portfolio of things. This can work in all businesses, not just technology ones, and helps give guidance and structure to leadership decisions to make improvements and continue growth. There are many methodologies out there including TOGAF, FEAF, and Zachmann.

However, what I’m going to present in this series is my personal simplified and practical version of EA. This methodology is based upon frameworks like TOGAF and FEAF, but I don’t adhere to all of the strictest processes that are defined by those standards. I find that this simplified method helps to introduce the topic and framework, which can then be built upon in the way that best suits the organization or person trying to do the implementation.

The graphic attached to this blog highlights a visual representation of what we’ll be talking about, and so for today’s entry I want to focus on the foundation that makes up the house of EA. Every house needs to have a solid foundation, and the house of EA is based on three basic concepts; Vision, Strategy and Knowledge. These three ideals are the basis upon which all of the pillars stand. They might sound like simple concepts, but let’s unpack them a bit so we’re all on the same page.

enterprise-architecture-drawingWhen we talk about Vision, what we’re referring to is the goal of where an organization wants to go. Vision is that driver that informs all other decisions. If you want to move your business forward you need to know and understand what the destination is that you’re shooting for. If you stumble blindly forward, you’ll end up making decisions that might seem right at the time, but have long term impacts that can actually set you back. Vision is linked to what Simon Sinek describes as “Starting with Why” (I encourage everyone to watch his video). Vision is directly linked with why you’re doing what you do. Vision isn’t concerned with how you get there, or what you do every day, but with the picture of the future that you’re trying to bring to fruition.

Without vision an organization will stumble forward and every plan will only meet limited success. There might be initiatives and projects that are rousing successes, but if they’re not tied to a vision of where the organization is heading they’re fleeting moments. They accomplish short term goals, but they don’t bring the organization to where it really wants to be. That is why Enterprise Architecture starts with Vision. If you don’t have a vision for your organization, then everything else will never fall into place.

A vision doesn’t need to be overwhelming though, it just needs to be attainable, and something you believe in. Let’s take an example of a neighborhood cafe to see what this might look like. You decide to start a cafe in your neighborhood because you want to create a place that everyone in the neighborhood goes to hang out and join in community with one another. Your vision is for a (profitable) place of community that helps bring a neighborhood together. You know when you’re successful if you’re making a living, and you’re seeing your neighbors in the cafe frequently, talking with other neighbors and building up the community. You’d see your vision achieved in a real and practical way directly by the people around you.

If you’ve got your vision, then what comes next? Vision isn’t enough to create something out of nothing, and that’s where the second element of the house of EA foundation comes in to play. Strategy is concerned with how you get to where you want to go to make a vision a reality. In Strategy all of those projects and ideas take shape and work begins to happen. This is where all the crazy ideas and plans that might be tossed about, get culled down into real, actionable, strategic goals.

Having a strategy means that you know what you’re going to do tomorrow, and the next day, to achieve the vision. You create efforts that have a real impact and put them into place to test them, and ensure they continue to move you on the right path forward. Good strategies are practical to achieve, meaningful to the vision, and just as easy to communicate to those around you as the vision is. One of the key features of Enterprise Architecture is the communication of all of these aspects to everyone involved, to ensure that all players are on board, and understand they why and how of day to day work.

Let’s put some strategy into our neighborhood cafe and see what it looks like. If the vision is a place of neighborhood community, then strategy should work to achieve that end. Finding ways to make the cafe a central point of life in the community would be one very practical avenue of strategies. Hosting political events, community fundraisers, or making space available to churches, mosques and civic groups are all viable strategies that would push towards the vision. People come together at the cafe, and when they’re there they see their neighbors, and community happens.

In a profitable venture it’s also important to make sure that the bottom line balances out, even if it’s over the long term. Therefore, strategies should always take into account the financial needs of the organization, whether that be a non-profit, governmental, or corporate. Each type of organization type will have very different needs and obligations, so it’s imperative to understand the nature of the organization when putting a strategy in place.

That leads directly into the third element of the house of EA foundation, that of knowledge. When I use the term knowledge in Enterprise Architecture, I’m not just talking about having smart people. Knowledge is that understanding of all of the assets, skills, talents, abilities, and resources that are available to an organization. As important as it is to have a vision and a strategy to get there, if you don’t know how to implement the strategy, or understand what your organization is capable of, you won’t get far. Knowledge is the key to making everything else a reality.

Knowledge isn’t just a cataloging of things, but Enterprise Architecture demands that you know what those things do and are capable of. If we move back to our cafe example, some of the pieces of knowledge would be the size of the space that you have to work with, the capabilities of the chefs to cook, the location of the cafe, and the tastes of the local community. Knowing all of these pieces of information allow you to make informed decisions about how to implement strategy to reach the vision.

If your cafe has a large outdoor patio space, then perhaps one strategy would be to make it dog friendly, and encourage people to bring their four-legged friends to the outdoor space (city code permitting) to hang out and meet with their neighbors. The investment of fire pits and other heat sources can make a patio more hospitable in cooler seasons of the year, and continue to give people a place to gather longer. Knowing the tastes of the community would also be key to helping bring people in and spend time together.

All of these pieces of knowledge help contribute to the overall goal of Enterprise Architecture. This is why these three elements are at the foundation of the house of EA. Vision, Strategy, and Knowledge create the key pieces upon which we can build up the rest of the house. Once we have these three elements in place we can start to dig deeper into how the rest of an Enterprise Architecture practice can come together. It’s important to remember that an EA practice is not the owner of the organization, but is the methodology by which the organization moves forward. Enterprise Architecture’s goal is to enable organizations to meet their goals and succeed in their vision.

One of the main criticisms of EA is that it is often seen as very ivory towered, and not practical. That is why I start this house of EA with the three bedrock foundations of Vision, Strategy, and Knowledge. Enterprise Architecture only exists to enable an organization to be the best that it can be, and at no point should EA practices exist for the sole benefit of EA. As we unpack the four mail pillars of EA in later blogs, it will be important to keep this foundation in mind at all times. Nothing that Enterprise Architecture does should negatively impact the vision or strategy of the organization, but it should aways be seeking to serve as a servant leader to the organization. The needs of the organization trump the purity of EA, and EA should always be looking for how to give the best of itself for the betterment of others.

Enterprise Architecture is an exciting young discipline, so I hope you’ll stick with me over the next few weeks as I continue to pull back the curtain and show how EA can be a key component in any organization.