Chapter 2
EAG Functional Framework

Unfortunately, there’s no such thing as architecture or governance in a box. It isn’t a simple matter of saying that you’ve chosen TOGAF or ITIL as your EA framework. Nothing out-of-the-box is going to be a complete drop-in solution. You’re going to have to build your own IT management solution, and you’re going to need a plan.

You need to be able to hang all the complicated pieces of your own program on a simple EAG framework, with as little re-inventing of the wheel as possible. You no doubt already have quite a few documented policies, standards, and processes in place, and you can fill in many of the remaining gaps by borrowing ideas from TOGAF, COBIT, and ITIL. However, you still need some sort of framework that will organize all the parts so you can see where those gaps are and prioritize them. You need a way of visualizing the complexity. You need a napkin drawing of the “big picture.”

The big problem with getting from where you are today to a fully functioning enterprise architecture and governance program is that it’s a big problem. There are an overwhelming number of different parts to keep track of without the use of some sort of system. Companies in every industry have been trying to come up with “some sort of system” for the past 40 years. Some of these systems have been successful, but many have not. You want to leverage what has worked, while avoiding the mistakes of the past.

Why architecture and governance programs fail

Many companies have tried to move forward with an enterprise-level architecture and governance program, and many of those programs have failed to show any business value. In my experience, these programs fail for one or more of the reasons listed on the following page.

In order to avoid these common routes to failure, you need committed leaders who understand the need to bring IT complexity under control. You need a simple, clear vision that spans all of IT, and focuses on supporting the business. You can’t simply ignore the last thirty years of best practices. Your program must be able to incorporate existing policies, standards, and processes with little or no change, and you need involvement from the IT departments you’re trying to manage.

Using TOGAF, ITIL, and more

Where we don’t have existing architecture and governance in place, we want to be able to easily adopt material from recognized best practices such as TOGAF, ITIL, and COBIT. The reason we don’t just adopt one of these industry standards is that none of them are going to completely suit your business. Indeed, each of these approaches has a particular focus – particular strengths and weaknesses. No matter what conceptual framework we come up with for our architecture and governance, we should easily map these industry-standard approaches to it. If your framework is so different that it can’t be related to industry standards, it’s time to rethink your framework.

Unfortunately, there is no one-size-fits-all EAG drop-in framework. Every industry has a different business model. Often business models can vary dramatically even within an industry. Different organizations will have different goals and will need different kind of support from their IT organization. Different organizations are at different levels of maturity and have different pre-existing infrastructure to accommodate. If this weren’t so, every IT department in every company would look exactly the same.

All the different EAG standards and frameworks claim to be describing the same thing. They all claim to organize and manage IT architectural complexity, yet each approach is quite different. Consider the story of five blind men encountering an elephant for the first time. Each describes the part of the elephant he encounters: a tusk, a leg, the ear, the trunk, the body. Each man experiences the elephant from his own perspective, even though they’re all attempting to describe the same elephant. ITIL, TOGAF, Zachman, COBIT, and others all claim to be describing architecture and governance, but they seem, on the surface, to be as different as the descriptions given by the five blind men. It’s our task to take all those different descriptions and figure out the common truth behind them. What does the architecture and governance elephant really look like?

Figure 2.1 “Blind men and elephant,” from Martha Adelaide Holton & Charles Madison Curry8

It seems all of those industry-standard approaches describe different combinations of IT functions and the things we do to manage those functions. So I would start my picture of the EAG elephant by creating a grid, where I list all of the functions IT performs for the business as columns, and all the things we do to manage those functions as rows. This grid is the beginning of our EAG framework.

When I start to place the different historical approaches on this framework, I find that

• NIST and Spewak mainly describe how IT functions fall into various domains of responsibility, so it’s probably going to be easier to follow that best practice if our function columns are grouped together by IT domain.
• TOGAF focuses more on policies and standards; with the most re-usable being those for the technology and security functions. Policies and standards aren’t functions; they’re how you manage functions, so we’re going to need rows in the framework for these important governance documents.
• ITIL focuses on listing the most common cross-industry functions, organizing them into high-level functional areas. Functions are our columns, but since there are so many IT functions, we need to follow ITIL’s example of grouping functions together into functional areas to keep the concept manageable. A large part of ITIL is process and role documentation. We want these important governance artifacts as rows in our framework.
• COBIT defines templates for documenting the policies, standards, processes, and roles that are complete and consistent across the enterprise. We don’t need extra columns or extra rows for COBIT, but when we begin to create the document artifacts in the cells of this grid, we need to be ready to steal freely from all the thought that COBIT has put into their templates.
• Zachman focuses on policies, standards, processes, and roles, but mainly for the software development lifecycle. We are going to be able to apply many of Zachman’s concepts when we begin creating the governance documents for those functions. Zachman also standardized which UML diagramming techniques, such as ERD diagrams, swim lane, and use case diagrams to consistently and effectively communicate complex ideas. We aren’t going to want to re-invent any of that.

Some of these approaches focus more on standards, some more on strategy, some more on processes. Some reference a few specific functions, like SDLC or security. However, when you step back and listen to all of these different descriptions of our elephant, a picture starts to emerge.

These various approaches generally share two major commonalities:

• Firstly, they all define lists of the functions IT provides for the business. They also organize these functions into meaningful, higher-level “functional areas,” which are owned by domain experts. To be clear, a domain can be comprised of multiple functional areas, and each functional area can be comprised of multiple individual functions.
• The second way these approaches are similar is that they each include a list of all the different tasks that must be completed to manage those functions. Some of these tasks fall under the category of architecture, or managing the future of the functions. Other tasks relate more to governance, or managing the day-to-day execution of functions.

That picture, in my opinion, comes together in the drawing below. I call this a Functional Framework, because the basic organization, similar to COBIT and ITIL, is a hierarchical arrangement of all the “things we do.” For each of these functions, we can document the relevant architecture and governance structures needed to manage that function, resulting in one cohesive vision of the IT infrastructure that supports the business. This is the napkin-drawing that we’ve been looking for to tie all of the IT complexity into a unified concept that is easy to understand and manage.

Like ITIL, this approach is focused on the functions (ITIL “services”) your organization does in support of the business. Suppose for a minute that you have a friend who works in the IT department at another company, perhaps even in a different industry. You meet this friend for lunch, and they ask you about your organization. “What all is your IT organization responsible for?”

Can you answer? In theory, everyone should certainly know what they’re responsible for, but in reality that’s a far grayer subject than it should be. Even if you can answer the main parts, can you immediately list off all the little peripheral responsibilities? If you can’t immediately bring them to mind,

• How do you plan a strategy for them?
• How do you create standards and policies for them?
• How do you analyze the broad impacts of new or changing business requirements?
• How do you clarify who is responsible for each?
• How do you remember them all when it comes time to plan next year’s budget?

We should all have a list somewhere of the things for which we are responsible. The first step in organizing your architecture isn’t changing org charts or creating an inventory of assets. The first step is creating a list of all the functions performed by your area of influence. These are the columns in the functional framework from which you plan your IT management. You can’t start planning until you know what it is you’re managing.

With that in mind, we’ll begin not with a discussion of how to manage IT functions, but with a discussion of how to create a list of the functions you’ll be managing. In our functional framework, that means starting with the columns (functions) before we get to the rows (management tasks).

Everyone’s functional framework will be different. Odds are that if five different people in your organization try to list the functions you manage, you’ll get five different lists. That’s to be expected. You must work together to compile an agreed-upon list.

What is a “function”?

Let’s clarify some of the concepts. Just what is a “function”?

Functions are things that happen, whether or not they are currently managed. From an IT standpoint, they are the things you do to support your business. Ideally, those “things you do” have a strategic plan, policies, standards, processes and roles defined, but they are still IT functions even if you’re just winging it today.

There seems to be a great deal of confusion regarding the differences between the things that are truly functions, and the things that are projects or job titles. Let’s address that right up front.

Functions are organization independent

You’ll be tempted to build your list of the existing IT functions by simply dropping in your org chart of departments, managers, and supervisors as the high-level functional areas, then having each list the detail functions they are responsible for within that department.

Whatever you do, avoid that temptation! This is critical. You’re not trying to document the way you’re organized today. The whole point of this exercise is that you are struggling today, and are trying to find a different, more streamlined means of managing IT complexity. Simply document the hierarchy of functions, not the hierarchy of your organization chart. Certainly you should consider all your job roles in order to discover and document the detail functions, but don’t impose a hierarchy of those functions based purely on the job titles.

In a later phase, you’ll want to make sure your organization reflects your functions, but that doesn’t mean you want to base your functional model on your old organization structure.

This can be a frightening thing to all the people you’re interviewing when compiling that list of functions. The impression is that, “Jobs are on the line” and “Empires will be overthrown.” In reality, this isn’t what happens. Implementing EAG may involve some job shifts, but that shift ends up creating positions rather than eliminating them. In my experience, you’ll find more management gaps than you’ll find management redundancy. What you’ll find is that there are some functions that one manager was technically responsible for, but never really focused on. By moving functions into related groups, you’ll more than likely actually be creating groups of functions that need new, dedicated teams. Maybe data dictionary responsibility falls to the developers today, but always suffers from lack of priority. After creating a functional framework independent of your current org chart, you may well decide that you need a new team to focus on metadata, including data dictionary, process documentation, references tables, and other descriptive information.

A functional framework shouldn’t split one function into two just because more than one manager works on it. You shouldn’t see functions such as “Sam’s application support” and “Sarah’s application support.” Those are organization breakdowns. Likewise, you shouldn’t see duplication of functions merely to separate full time employees from contractors. If the function is the same, then don’t split it up because of an artificial distinction imposed by your current organization structure.

At the high level of the functional framework, you shouldn’t see duplication of function for different departments or lines of business. Those breakdowns may be necessary to run the business, but at the highest level, the architecture and governance for those areas will be defined only once per function. Don’t worry! You’ll see as we progress that there’s plenty of room for departmental flexibility deeper down within this framework.

Don’t change your functions to match your organization – change your organization to match your functions.

Functions are independent of projects and time

Your functional framework shouldn’t contain a list of projects. While you’re responsible for projects, the purpose of IT isn’t to create projects; it’s to perform the functions that are required to support the business. Projects end after a short period. Functions don’t end without a significant change in the business model. If you decide as a company to move all your software to a third-party hosted cloud solution, your software upgrade/maintenance function may end, but this would be very rare. Projects end all the time.

Your functional framework shouldn’t contain any temporary tasks. With rare exceptions, temporary tasks are really projects, and should be treated as such. Don’t ignore the work – but do assign the task to a high-level “function.”

Organizing your functions

The reason architecture and governance are so difficult is that they are complicated. There are a lot of functions - so many that an exhaustive list would be unmanageable. The sole purpose of this book is to give you a practical way to organize and manage that complexity. One key component of our EAG approach is to cluster functions together into manageable groups, called functional areas.

This organization of the complexity has to happen before you can start to manage it. That’s the whole point of the functional framework – organizing how you think about all those thousands of details into something more conceptually understandable, then putting the management structures in place on those abstractions.

How then do you go about building this functional framework with its hierarchy of functions?

The organization layer of the functional framework

At the top level, this organization structure is divided into business and IT.

Perhaps this is a bad thing. It promotes “us versus them” mentality, and is often an obstruction to true teamwork. As we’ve said before, one of the main reasons for architectural and governance program failure is that IT tries to go it alone, building out complex programs without any business input. Putting the business in the framework ensures that they are a part of the discussion.

Once you leave the ivory towers of academia, you’ll find a huge difference between the answers given by a computer science professor and the answers that work in the real world. I love to say, “We are a business, not a science project!” I have it written at the top of the white board in my office, and I’ll keep coming back to it throughout this book.

When left to their own devices, IT people sometimes come to believe that the world revolves around them. I know - I am IT people! We could have dispensed with the organization level of abstraction and begun with the four EA domains, which do call out business architects as a separate domain. But I suggest that we want to call attention to that IT/business divide, to the fact that we work for them.

The reason the organization tier is so important is the way most company’s org charts are built, where the business and IT roll up to different C-level executives. The point of the organization level of this framework is that you are going to have to get executive sponsorship from both sides of the house, or from a level that is over both. You can’t build a successful architecture or governance program using IT-only resources and IT-only sponsorship.

In some cases, your business is IT. I worked for many years for a company that developed software for the finance industry. We weren’t a financial institution, but we did develop and sell software to financial institutions. We were a software development company. In one sense, the entire company was IT. However, even in that context, there are people whose roles involve decisions about the business of the company: what products and features do we need to focus on to remain competitive? What are the bottlenecks in the infrastructure that supports our sales, marketing, and customer service organizations? Should we be investigating new lines of business or expanding our existing business through new channels?? The people whose job it was to answer these questions were our “business” people, even in an IT-centric software development company.

You always have business people, and they always need to be part of in your enterprise architecture planning. Not just involved, but actually leading the discussion. Therefore, they need to be included in your functional framework.

I’ve seen some sources recently9 that separate the organization layer differently. You still have the business organization, but the IT organization is split out into a semantic/content organization (the information domain) and an infrastructure organization (the application and technology domains).

In that model, the thought process is that there are three levels at which you manage IT complexity:

• Functional Interoperability – consistent, integrated business processes
• Semantic Interoperability – consistent, integrated business information and exchange structures
• Technical Interoperability – consistent, integrated software and hardware infrastructure

This is a relatively new trend. I’ll mention it here, but this approach doesn’t reflect the way IT functions are typically managed or the way IT departments are typically organized today. For the remainder of this book, I’ll consider the information domain to be part of the IT organization. In the context of our goal of a functional framework that can be used to make the management of IT functions simpler, I don’t want to introduce anything that wouldn’t be intuitively understood by all the players. That said, if your company is organized this way, it’s a small change at the organization level of the framework, and the rest of the discussion still applies.

The domain layer of the functional framework

At this level of the framework, we bring in the architectural domains defined by Zachman, Spewak, and the NIST model.

Each of these architectural domains represents different expertise and different priorities. These will be discussed in detail later. Unless you’re a very small organization, don’t be tempted to assign the architecture and governance for two different domains to the same resources. Even if you can find someone who truly understands the needs of each, no one can wear both hats at the same time. It’s something like the need for separating development and operations .

You can’t let your application architects take care of the information architecture, and so forth. You need individual architects to focus on each domain and champion its architectural needs. This will create a lot more conflict and drama, but the organization will be better off because of it.

According to Spewak and NIST, these domains are not peers of equal priority and precedence. The business architect is the real driver, defining what functionality the business needs. The information architect designs the information needed to support those business functions. The application architect designs the applications needed to build, maintain, and deliver the data, and the technology architect designs the infrastructure necessary to host the applications.

Think of Enterprise Architecture as a rope. Business is out front, setting the architectural direction and pulling everything else behind it. Information architecture is next in line, being pulled by the business, and in turn pulling application architecture, which in turn pulls the rope that guides technology architecture. Starting your EA program with technology architecture is rather like trying to push a rope.

Many EA programs start with their priorities reversed. Technology is in the driver’s seat, with application close behind. Information was invited as an afterthought, and business was not invited at all. I think there are several reasons why this happens so often:

• Technology is more portable across industries, so a larger body of useable implementation and best practices has been available to draw upon for much longer than other domains. This is why TOGAF is much more relevant to the technology domain than to the information and application domains. Technology is the most mature domain in terms of the availability of domain-specific architecture and governance best practices.
• Technology, by its very nature, is more centralized. We’re in an age where most application developers still focus on one or two applications, but technology resources host solutions that are shared as a service across the enterprise. Security concerns, leveraging virtual servers and disks, consolidated backups and disaster recovery – these are just a few of the compelling business cases for pooling technology into a centrally managed data center. Because of this, the technology domain has probably been working at the enterprise level in your organization longer than the other IT domains, with more mature organization structures to support enterprise-wide decision-making. This makes the technology domain a natural choice for leadership in enterprise architecture discussions. The technology domain has the most mature org chart roles.
• Many of the most pressing EAG issues today appear to be technology-domain issues. Compliance with security mandates, for example, is at the top of everyone’s list of objectives. Security must be addressed at an enterprise level, and is often the project that’s driving companies to focus on enterprise architecture and governance in the first place. Because of this focus, the technology domain seems a natural choice for leadership.

However, before you set up your programs with the technology domain at the helm, please review the best practices that have held true for the last thirty years. Beginning with technology is a case of the tail wagging the dog. You don’t build technology first, and then consider application, data, and business needs. Technology issues are definitely in the spotlight today, but they are there because of business needs, not the other way around. While many consider the business requirement for security to be a technology domain issue, I suggest it belongs to the information domain instead. You aren’t securing cabling and disk drives; you’re securing the data on the cabling and disks. You can’t implement a PHI, PII, or PCI security solution until you understand what the data requirements are. Yes, in the end, a good part of the solution will be in the technology layer, but the requirements don’t ever begin there. Don’t skip past the domain precedents recommended by Spewak and NIST thirty years ago, or your programs will not be business focused. This is a business, not a science project.

Full-time versus matrixed domain EAG architects

I’ve seen two different approaches to setting up an Enterprise Architecture and Governance organization, but only one of them should be considered a best practice.

One approach is to put someone in charge of Enterprise Architecture and Governance and have the all the domain architectural roles report directly to that EAG director as dedicated resources. The other approach is to leverage architects that work in different areas of the company, but come together regularly in a dotted-line, or matrixed reporting structure:

• Full-time, dedicated architects reporting directly to an EAG director, working full time on strategic architecture.
• Matrixed architects, reporting to different parts of the organization, working on real projects, with dotted-line relationships to a full time EAG director.

It might seem counterintuitive, but I’ve found that the direct-reporting architect approach doesn’t work well. In fact, I’ve never once seen it be successful. In every case, it becomes a silo of people who make decisions amongst themselves, then pass those decisions as mandates to the rest of the company. There are several problems with this approach. The isolated architects are:

1. Disconnected from reality. These architects are not in tune with the daily challenges of the company and are operating in the dark, despite best intentions. This results in elegant solutions that ignore practical integration messiness, timelines, and budgets. What tends to come out of these organizations look like the ivory-tower, perfect world solutions you would give your college professor in response to an exam question, and not what’s actually useful in the real world. A three to five year strategic vision isn’t intended to paint a picture of architectural nirvana. Rather, it is a best-case, real-world scenario where there are still a lot of legacy infrastructure limitations in the mix. It probably doesn’t make business sense in that period to invest limited resources in replacing those older infrastructure components rather than building out more important new functionality around them. A perfect-world infrastructure vision is more likely an IT architect goal than a business goal. Once again, this is a business, not a science project.
2. Generating ill-will. This becomes us versus them, where they are trying to tell us how to do our jobs, when they don’t have a clue what’s really going on. This is taxation without representation. Architects working on actual projects can’t be thrilled about having design constraints imposed upon them by a group of people with fancy titles who work in isolation, with no effective input from the average person.
3. Not growing. The architects who work in isolation are not growing their skills through real world implementations. Their titles give them a false sense of their own abilities, but in this world of rapidly changing technology, you need to be constantly learning and applying new skills in real world contexts.
4. Out of touch with budget. These architects working in isolation tend to have a great deal of difficulty tying their goals to business value. Their strategic roadmaps are self-centered and unrealistic. They aren’t just isolated from their IT peers; they are isolated from the fiscal reality of the business operations.
5. Not in a position to influence. Because they are not part of the normal business project pipeline, they don’t have the opportunity to influence the architecture of real business initiatives.
6. Become a dumping ground. Senior resources are rare and valuable. If you want access to the most talented resources in your organization, you’re going to have to be willing to share. You can’t hire from outside, because for these positions, you need people who know your infrastructure intimately. If departments believe they’ll be losing their best people, they’ll send you instead the people they would prefer gone. To them, it’s an easy way to take out the trash without going through the confrontation and emotion of firing someone.

I’ve found that the far better approach is to take real-world architects facing real-world problems and allow them to carve off a portion of their schedule to meet together under the shelter of the EAG umbrella and hash out solutions together. The one person in charge of the EAG program is fully dedicated, but all of the architects underneath that position are matrixed in from other areas. This works far better than the ivory tower approach, giving individual architects a voice to air real-world concerns and a chance to “own” the resulting decisions.

The full-time, dedicated architects in the ivory tower tends to result in a group of out-of-touch elitists coming up with rules that no one else is committed to, architects that are out of touch with the real world problems and the project pipeline, and an architectural roadmap unable to find business value in each step.

The second approach tends to result in real world issues being addressed by the best resources within your company. The people actually doing the work throughout the organization then champion the decisions.

Enterprise Architecture and Governance (EAG) program roles

This discussion of the organization and domains of the functional framework provides a good opportunity to discuss the roles involved.

• The Executive Sponsor
  • The C-level executive sponsor must be on the business side, preferably a COO or CEO. IT architecture and governance cannot be an IT internal project or it will lose focus. The sponsor will need to “get” the concept of investing in the architecture and governance necessary to effectively and efficiently manage the IT functions that support the business. CIO, CTO, CDO, CAO positions should also be supportive of the mission since their most valuable resources will be investing large amounts of time to support it, but the business should ultimately be in charge. You must constantly remind IT that they work for the business, not the other way around. IT does everything to support the business. The executive sponsor won’t actually be spending a great deal of their own time, but they will need to actively champion the commitment of the necessary resources (human and financial) to the mission. The director may also occasionally ask the sponsor to resolve conflicts that affect the program. Their primary responsibilities in this effort are to ensure resource allocation (staffing and funding), to clarify priorities, and to drive cross-functional cooperation. In this capacity, the sponsor must be an active participant in the program. They would rarely attend EAG meetings, but would instead be kept current through the EAG program director.
• The EAG Program Director
  • The EAG program director needs to be truly domain independent, and not favor one domain over another. Ideally, they are a direct report of the executive sponsor.
  • The EAG program director should be the only full-time dedicated resource on the EAG program team, with the exception of support resources like technical writers and project managers.
  • The EAG program director needs to have excellent leadership skills and the ability to keep a vision in the team’s head of what they are trying to accomplish in order to keep everyone heading in the same direction. Directing architects is more than a little like herding cats.
  • The EAG program director needs to have top-level interpersonal skills, especially conflict resolution and the ability to bring discussion back from sideline issues. A good architect is someone who has strong opinions and a passion to communicate and convince. Unfortunately, this means that if you have the right people in the room, there’s going to be a lot of drama. This comes with the territory. If they weren’t passionate and opinionated, they wouldn’t be good architects. If you find that consensus is coming easily, you probably don’t have the right people on your team.
  • The EAG program director needs to be able to speak both business and technical. They may not be the equal of the domain experts, but they need to be able to understand the discussion well enough to guide it. The director can’t be simply a meeting facilitator. You could get a project manager for that. The director needs to be able to lead, to make decisions, and have the respect of both the business and IT. The director may not be a domain expert, but they should be an expert in the concepts of enterprise architecture, the goals of the program, the “what,” “why,” and “how.”
  • The EAG program director needs to be able to work closely with the sponsor and other executives to keep them informed of the progress and aware of the vision of the program. It’s the job of the director to keep these executives engaged and committed so that they’ll continue to support the involvement of the domain architects and enforce the decisions made by the team.
• EAG Program Domain Leads
  • Each EAG architectural domain needs to have an official, recognized leader to whom the other architects in that domain report. This domain architect can still be a part-time, matrixed resource, but must have the respect of the other architects in their domain, the leadership ability to help the EAG program director maintain control in meetings, and the initiative to keep domain-specific work products moving along between meetings.
  • In many organizations, the domain leads have a day job where they report directly to senior VPs in their area. The business domain lead might report under the COO, but the technology domain lead might report under the CTO, the application domain lead under the CIO, and the information domain lead under the CDO/CAO. This reporting structure is critical to establishing executive sponsorship, prioritizing EAG work despite pressing daily demands, and enforcing EAG decisions.
  • The business architect is the single most important resource on the team, and the hardest position to fill. They have to truly understand the business model, and be actively engaged in discussions at the highest levels on the business side. They need to have their finger on the pulse of the day-to-day business operations and be able to see which IT functions are working well for the business and which are not. They need to be engaged in business planning and be able to foresee future IT functionality needs and bring these to the rest of the EAG team for discussion. They need to be able to articulate requirements at the business level. We’ll talk more about this when discussing the business domain, but you need to understand up front that this person will be the voice of “the business” to the EAG team. They will cast the business vision that all the other domains will be supporting. These are very special, rare people. Spend the time to find the right fit, because they can singlehandedly cripple the program.
• EAG Program Architects
  • Even at the largest organizations, you’ll be hard pressed to get anything done with more than 5-8 architects per domain. The domain lead is just like any technical leadership position when it comes to the size of the team they can manage successfully.
  • Each EAG program architect needs to be able to dedicate at least 25% of their time to enterprise architecture and governance related activities without suffering ill-will from their managers
  • Each EAG program architect needs to be a subject matter expert, not someone who was included for political reasons. They need to be an expert in their IT field and an expert in the domain infrastructure of your company. This may be the most difficult part of building a good team, but this is one of those cases where it’s important to put the good of the company ahead of the feelings of an individual, even if that person has worked at the company for decades. One or two ineffective people on the architecture team can destroy the effectiveness of the entire team - a team whose time is far too valuable to waste.
  • Each EAG program architect needs to be able to put the good of the company over their own agenda. They shouldn’t decide architecture based on what keeps work flowing to their department. It’s a good thing that your architects have strong opinions about how things should be done, but they need to be able to listen to opposing views and come together in a compromise that is best for the company, not just for their domain or the department of their day job.
  • Each architect must bring strong opinions about “how things ought to be done” and be willing to defend those opinions clearly and professionally. Yet, that architect must be willing and able to adjust their opinions with grace and good will based on the feedback from the team, putting the good of the business above the desire to win every argument.
  • Not every developer has what it takes to be a good architect. You may have a software developer who is a true wizard when it comes to writing code, the best in the company. Nevertheless, that may not translate to the ability to visualize what the infrastructure should look like five years from now.
  • I would want to make sure each of my EAG domain architects were well versed in the relevant best practices for architecture and governance. The technology architect should be familiar with TOGAF. The Application and Information architects should be familiar with the Zachman Framework. ITIL education would be a huge benefit for the business architects. In addition, all of your architects should be familiar with any regulatory standards (e.g. NIST CSF, HITRUST).
  • There’s a whole spectrum of planning horizons in your company, from who focus on a horizon five to ten years in the future, to those who focus on what is happening in the operational environment right now. An EA architect probably has a day job with a very practical, tactical focus at the scope of a single project, looking at a horizon two to three months in the future when the project will complete. They need to be mentally flexible enough to step away from that tactical mindset and function in the context of EA on a strategic vision that is more distant, and more idealized.

• EAG Technical Writer
  • The EAG technical writer is usually a dedicated, full time resource reporting directly to the director of the EAG program.
  • The EAG technical writer is responsible for documentation consistency. I would want them to have COBIT training as soon as possible.
  • The EAG technical writer is also responsible for the enterprise architecture and governance repository, where the various architecture and governance artifacts are collected, maintained, and communicated.
• EAG Project Manager (a role sometimes performed by the EAG Program Director)
  • The project manager is usually a dedicated, full-time resource reporting to the EAG program director.
  • The EAG project manager is responsible for managing the work tasks involved with completing and maintaining the enterprise architecture rollout: the strategic vision and tactical roadmap. The business architect will assign priorities, but it’s the project manager who’s responsible for making progress toward completion of the gaps in the framework.
  • In the same manner, the EAG project manager is responsible for managing the tasks and resources to complete the executive governance rollout: the tasks involved in creating and approving the policies, standards, processes, and roles. This completion involves both the breadth of the framework (documents for all functions in the framework), and the completion of the depth of the framework (documents for all information systems covered by the framework). If the SDLC documentation is performed separately by each information system, the project manager has the responsibility of tracking that each of those system-level documents are completed and handed over to the EA technical writer.

EAG program director

Because they are responsible for the EAG program and are independent of the EAG domains discussed in detail later in this book, I want to take just a bit more time talking about the EAG program director role.

Any architect worth their salt will have a good deal of experience-backed confidence, and a strong vision of the way things should work “if they had only asked me.” You get all these large egos in a single room and things can degrade rapidly unless there is a strong, respected leader who can tell when an argument has passed from legitimacy into obstinacy, and can nip it in the bud while maintaining an environment of professionalism and mutual respect. This group of prima donnas will roll right over someone who is weak technically and can’t call their bluffs or tell when the discussion has gone down a bunny trail. Likewise, a leader who can’t or won’t step in and command respect and order will find they’re trying to herd cats that are all scampering in different directions based on their own agendas. The EAG program leader must be technically strong, professionally and emotionally mature, and must understand the true purpose of enterprise architecture. They must have a clear vision for the goals of the program and must be able to clearly articulate that vision. The EAG program leader needs to be charismatic enough to build team identity and excitement about the program’s potential.

The director needs to be able to make decisions when necessary to move the architecture forward. The individual architects are the experts, not the leader. However, when experts can’t agree and facilitation/arbitration isn’t working, the leader needs to be able to step in and make a fair, informed decision. Leaders who can’t make decisions suck the energy and morale right out of the program, making it ineffective. Leaders who appear to the team to be making biased decisions or decisions above their level of understanding are even worse that leaders who make no decisions at all, because they disenfranchise the members of the team. If no decision is being made, the architects will still hope they can influence the direction of the program, but if decisions are biased or being made by someone who doesn’t have a clue, the architects see the program as already headed over the cliff. There’s no reason to stay and waste their time watching.

In order to have the authority to make and enforce decisions, the EAG program director must also have the full support and assistance of the most senior management. To this extent, it’s important that the EAG program director be positioned high on the org chart, where they have the full ear and confidence of executive management.

The EAG program director is also the one who is going to be responsible for recognizing that a resource assigned to the team is not working out, perhaps unable to see beyond their domain, work at a strategic horizon, or remain professional during stressful situations. They are responsible for returning these resources to where they can provide the most value to the company, allowing the EAG team to function smoothly and efficiently. This isn’t easy to do. Make sure your director is someone who can and will make that call.

Let me describe one of the more effective and mature EAG programs I have been involved in.

I worked at a large mobile phone carrier for many years. The CEO of that company was often quoted as saying, “Our two most important assets are our people and our data.” When that company decided to set up an EA program, they reorganized the entire IT organization so that the CIO had three senior vice presidents reporting to him, an SVP of Information Management, an SVP of application development, and an SVP of Technology. Each of these SVPs had a team of architects reporting to them, led by a director-level domain architect. They brought me in as the Director of Information Architecture, reporting to the SVP of Information Management. My peers and I were matrixed (a dotted line on the org chart) to a VP of EA, who actually reported to the SVP of Application Development. Ideally, we should have reported to a business-side executive sponsor, but fortunately, there was also a truly brilliant person from the business side matrixed in as the Director of Business Architecture. In a room full of the brightest minds in the company, I attribute the success of that EA program more to the business domain architect than to any other single person.

The EA program at that company put together a program that took what we felt were the best parts of Zachman, NIST, Spewak, and TOGAF.

From Zachman, we took the idea of a framework of domains communicating together at various levels of abstraction using agreed upon artifacts. We all took the Zachman classes and basically used the entire framework, except we didn’t drill down more than two layers of abstraction on the “who,” “when,” and “why” columns, all of which fell to the Business Architect.

From TOGAF we lifted a large number of best practice policies and standards. Most of these related to our technology architecture simply because that’s the most transportable across industries, but we were able to adopt some standards and practices from other areas of TOGAF as well. Many of the standards in TOGAF have been developed in response to national standards such as HIPAA, ISO 27000, COBIT 5, and NIST 800-53. The TOGAF model was at that time thought by our security office to be an excellent foundation from which to achieve regulatory compliance or standards body certification, especially those involving security.

From Spewak, NIST, and others, we took the concept of a hierarchy of supported decisions. The CEO set the vision for the company, typically in the form of “the five things we need to focus on this year are…” The business decided what functionality was needed to support the company goals. The EA program took it from there, led by the Business Architect.

I’ll discuss the individual domains in detail in later chapters. For now, let’s return to our discussion of creating a hierarchical list of the IT functions that fall to these domains.

Creating the hierarchy of functions and functional areas

In general, there are two ways of taming complexity on any subject, depending largely on whether you’re building something new or trying to get a grasp on complexity that already exists. Both involve creating a conceptual hierarchy with a small handful of concepts at the highest level of abstraction, each of which breaks down into more and more pieces as more detail is fleshed out. At the highest level, the picture needs to be simple enough for everyone to visualize and understand. This is your napkin drawing!

So, how do you start building the hierarchy of functions in your own framework?

One approach would be to start by looking at a generic framework or one customized for another company or department, then modifying it as necessary to fit your needs. Don’t be afraid, though, to make fundamental changes to that model where it doesn’t reflect your operations. If your architecture team wants you to look at TOGAF as a reference model outside of technology and security, you’ll be doing a lot of this.

Another approach would be to make a list of all the functions for which you’re responsible, then start grouping them together in clusters of related functionality, somewhat like putting a puzzle together by first grouping together pieces by shape and color. Again, make sure you don’t list projects and job titles; list actual functional responsibilities.

The difference between these two approaches really comes down to whether you’re building the framework from the top down, or from the bottom up.

Top-down approach

As someone who came up through the programmer track, I can attest that learning a programming language is trivial. I once landed a job that required knowing a program language I had never used (FORTRAN), and learned it over the weekend before starting the next Monday. No programmer reading this is going to be impressed with that claim.

However, learning a programming language isn’t the same as learning to program. The hard part of learning software programming, the part that takes years to master, is learning how to take a complicated problem and break it into smaller and easier problems. If you do that enough times, that one unimaginably complicated problem becomes several dozen (or hundred, or thousand) very easy problems. You start at the conceptual top, and work your way down to the implementation details. This is the top-down approach. As you may recall, this was the approach used by Zachman thirty years ago. Work out the highest level of abstraction first before dropping down to the more detailed layers. Don’t get lost in the forest right at the beginning.

In this approach, you see whether the first level of abstraction suits your organization before digging too much into the detail below. This approach works well if you’re struggling with being overwhelmed, and need to break the problem down into smaller pieces. It also works well if you suspect that you’re going to have a lot of pushback from old-order managers and supervisors who are going to want to simply document the organization structure that exists today. It took a long time to reach the position they hold today, and they are good at it. They have no stake in what they perceive as starting over.

By starting with a high-level abstraction of functionality, you may have an easier time developing consensus than if you dive immediately into detail functions that are clearly someone’s personal territory.

Bottom-up approach

In other cases, you may start with the details and organize them into larger and larger conceptual groups. As an example, I own a lot of books. I have bookcases everywhere my wife will let me put them; many of the shelves stacked two layers deep. In order to find anything, I had to create some kind of organization. Managing all the thousands of different books in my house has many similarities with managing all the thousands of different IT functions in your company.

I group books together in ways that made sense to me: classics, science fiction, religion, Arthurian romances, books illustrated by certain artists. I have so many books by some of my favorite authors that I give them their own dedicated shelves. It makes more sense to me to keep these books together than to disperse them throughout my library by title or subject. Over time, the collection has rather arranged itself based on how the books are accessed and managed. I have yet to have grandchildren, but I have a collection of wonderful children’s books on a low shelf in a sunny room. Rare first editions are kept in a protected barrister case in a room with no direct sunlight.

This isn’t the Dewey Decimal System. You would no doubt organize it differently. My wife keeps borrowing my books based purely on the color of the covers to put together little decorating vignettes throughout the house. That’s just wrong! My system works for me and my unique collection of books. It’s grown into place over the years, and is perfectly suited to organizing the chaos that is my library.

In a bottom-up approach, your functional areas will likely emerge organically in this same manner. Starting with the details, group them together based on similar functionality and governance requirements, and then group the groups until the number of the highest-level groups is manageable.

In the bottom-up scenario, you start at the detail level, making a list of everything your organization does, in no particular order. Just toss in everything. We used to call this “green-lighting,” where everything is just piled together with no particular order, precedence, or ownership. Just make lists:

• Think about what functions are performed by each division of the organization you’re modeling.
• Look at timesheets and project lists for the types of functions that are being done, and derive function from those projects. Don’t make a list of projects!
• Look at your strategic planning documents also – some of your organization’s functions may be very immature or even non-existent today, but you want to make a place for them in your plan.
• Look at the detail level of the “sample” functional framework to jog your memory of things you might have missed.
• Look at frameworks such as ITIL to get ideas, but don’t be married to their lists, which were originally created more than twenty years ago.
• Make sure you involve the business. The whole purpose of IT is to provide services for the business. It’s often quite illuminating to ask the business what functions they believe you provide for them.

In keeping with my pursuit of “the big picture,” a few years ago I decided to pursue a master’s degree in theology. The seminary professors taught us to interpret scripture by first understanding what it meant in its original context, then to derive the universal “truth” out of that context, and finally apply that truth to today. Oddly enough, I find that training more useful than you might imagine when digging through frameworks from the past trying to understand what the framework was originally meant to accomplish, then extracting the timeless intent and interpreting it in today’s context. It’s less important that we reproduce how things were done in the past than that we reproduce the intent of those things in a way that is appropriate for today.

The typical real world approach

In reality, you won’t use either the top-down or the bottom-up approach exclusively. You’ll probably start with the standard top-level groupings we’ll discuss in a minute, then start putting all your detail functions and setting them on the appropriate functional shelf. Every once in a while, you’ll find a function that doesn’t fit well in these high-level functional areas, and you’ll need to adjust your structure a little at the top of the hierarchy; making a new shelf. Most of the time the top-level areas will come first and you’ll file the details under them. Occasionally, though, you’ll run across a detail function that will generate an entirely new high-level functional area. In the real world, building out the hierarchy of functions is an iterative process, both top-down and bottom-up depending on the moment.

I suggest making that list of your existing detail functions, then using the sample functional framework to organize those functions into a hierarchy, making modifications as needed along the way.

One thing you may struggle with is the temptation to list business functions, such as retail sales and advertising, rather than IT functions such as software development or hardware support. The purpose of the functional framework is to manage IT function complexity, not to manage the business. You need to ask yourself, “In the retail sales and advertising area, what are the IT functions?”

In theory, you can have as many levels as you need in the hierarchy of your functions. But in the real world, having too many layers just means that the hierarchy itself is too complicated. There’s no need to keep breaking the problem down once the detail pieces are easy enough to understand and manage. I find that just two levels are about all that’s needed in the framework itself. Any additional complexity can be fleshed out within the detail documentation rather than in the framework. In fact, that’s the determining factor. If the “functions” are all going to end up using the same policy, standard, process, and role documents anyway, then there’s no need to put any more detail in your functional framework. Leave the details for the document artifacts to spell out. There’s no need to list a function for hardware support of retail sales and a separate function for hardware support of advertising if the hardware support standards, process, etc. are identical. Keep your framework simple!

While you should feel free to organize your functions into functional areas however seems best to you, there’s a well-worn path that you should at least consider following before you start grouping your books by the color of the covers. The typical high-level functional areas that most companies will need to support are:

• Information lifecycle management functions, including:
  • Information collection functions
  • Information modeling functions
  • Information quality functions
  • Information security functions
  • Information analysis functions
  • Information delivery functions
  • Information end-of-life functions
• Software development lifecycle functions, including:
  • Software development request functions
  • Software development requirements gathering functions
  • Software development approval/prioritization functions
  • Software development estimation/budget functions
  • Software development project management functions
  • Software development architectural requirements functions
  • Software development technical requirements functions
  • Software development coding/unit testing/code review functions
  • Software development user acceptance testing functions
  • Software development system testing functions
  • Software development change management functions
  • Software development implementation functions
  • Software development support functions
• Software infrastructure lifecycle management functions, including:
  • Software request/approval functions
  • Software vendor selection/POC functions
  • Software acquisition functions
  • Software install/configuration functions
  • Software licensing functions
  • Software security functions
  • Software release management functions
  • Software end-of-life functions
• Hardware lifecycle management functions, including:
  • Hardware request/approval functions
  • Hardware vendor selection/POC functions
  • Hardware acquisition functions
  • Hardware install/configuration functions
  • Hardware licensing/inventory functions
  • Hardware security functions
  • Hardware release management functions
  • Hardware end-of-life functions

This is by no means an exhaustive list. It’s just enough to show you how most of the IT functions you try to manage can be grouped into some high-level groups. You should at least consider using a structure along these lines before you try to reinvent the wheel. Many companies organize their IT management this way, but the functional framework concept will support other approaches if you feel strongly about it. The advantage of using lifecycles is that it’s an overall concept that most everyone will understand. Arranging them this way gives everyone confidence that the framework is conceptually complete, and the functions don’t overlap. Moreover, if you do decide one of your functions is missing from this list, it should be obvious where that function belongs.

Of course, your business may demand other high-level functional areas - other shelves for a unique collection of books. Most businesses involve managing people, not just data, hardware, and software. How are the lifecycles of personnel managed? In most companies, these functions are regulated to Human Resources (HR), where the person-lifecycle is managed through very specialized software that typically doesn’t involve a lot of IT intervention. You manage the HR data, software and hardware, but you probably won’t get directly involved in the business functions. On the other hand, if your company is a recruiting agency, a school, a hospital, or some other industry where a major component of the business itself involves managing a “person” lifecycle with specialized IT functions, you may need an entire functional area just for those. Just make sure that the IT support functions themselves do not better fit under another, existing functional area. Remember it’s the IT functions we are managing.

Another common decision is to call out in a separate functional area those generic services that support many functions. You might, for example, abstract the print management functionality out of many applications into one managed function. You may decide to create a separate high-level functional area for functions that support other functions, a systems services functional area. You can have information services (master data management), applications services (print services), and hardware services (SAN virtual disk).

While this is acceptable, it isn’t generally recommended, as will be discussed in detail in the IT domain sections later in this book. More detail just makes for highest level of abstraction more complicated and therefore harder to manage – which was the whole point of this exercise. You’re aiming for a simple napkin drawing.

If you aren’t going to manage those functions materially differently than other information, applications, and technology in terms of architecture and governance, then there is absolutely no value to cluttering up the napkin drawing. This framework exists to make IT management simpler, not to feed the ego of someone who wants to see their pet project called out for special attention.

How you organize your functional hierarchy is up to you. Do you want a separate security functional area that includes the functions for hardware, software, and information security all in one place? Alternatively, do you want a separate security function in each domain? Either answer might be correct for you, depending on how you’ll manage the strategic vision, the policies, standards, and processes for security across these functional areas.

Odds are that your information, application, and hardware security functions will have separate policy statements and will be part of separate processes, in which case you would be better off separating out information security function into the information lifecycle functional area, and software security functions into the software lifecycle functional area. Remember, all the architecture and governance for these functions is going to have to be captured in documentation.

When trying to determine which functional area a function belongs in, ask yourself in which document it would make the most sense to place the architecture and governance. Information security includes defining data sensitivity labels (PHI, PII, PCI), and standards for masking, encrypting or de-identifying information appropriately for different roles in different environments. Software security focuses on provisioning and de-provisioning access to data, and technology security focuses on physical asset security10. Since the security-related policies, standards, processes, and roles for each domain will be different, I see no advantage to consolidating all the security governance into a single function.

In this case, your functional framework helps clarify your thinking about the functions you are managing, revealing that your security office must be staffed by experts from all the EAG domains. Placing the function of identifying PII data in the information domain makes it clear that the technology architects can’t own all of the security-related functions. These kinds of realizations are why we use the functional framework, because it represents IT complexity in a simple, meaningful representation that helps clarify our thinking and discussion about managing IT functions. This isn’t a side effect of the framework; it’s the primary purpose of the framework. We’ll discuss this topic in more detail under the security function in each of the domains in later chapters.

You shouldn’t expect to completely flesh out your entire list of functions and functional areas before starting to use the framework. You should do the best you can, but acknowledge that there are some areas that will need more attention later. Your HR area performs many important functions like cutting your paycheck, but it wouldn’t be uncommon to leave that functional area at a high level or missing entirely until some point when IT architectural involvement is needed.

Despite all the insistence that everything starts with the business, you will almost invariably begin with your existing IT functionality when building your list of functions. After all, EAG came into existence as a response to the growing complexity of existing IT. As we will discuss in the chapter on the business domain, the business functions are added to the framework as the business asks for IT assistance. Even when you begin fleshing out your framework artifacts with IT functions, you need the business architect involved to keep the focus on business needs. All those existing IT functions were once business needs, and they still only exist to serve the business.

One good reason for documenting these existing functions is that it may actually be a regulatory compliance requirement. In many cases, if you’re being audited, you will need to be able to “prove” that you have process controls in place. Auditors are used to hearing good stories about the processes you have in place, but will always ask for the formal documentation. We recently underwent a pre-audit in preparation for HITRUST certification, and most of the findings were documentation-related. You’re going to have to produce the process documentation across your entire enterprise (and logs to prove those processes are being followed) or you will fail the audit. Most maturity models require process documentation before you can advance past Level 2.

It can also facilitate leadership transitions. Even the most gifted leaders will benefit from taking the time to clearly define and communicate how they do what they do. If the leadership truly is gifted, they’ll eventually move up or out to other responsibilities, and the person who takes up the reins will have a much easier transition if everything is documented. Otherwise, the organization will soon be stumbling around in the dark, trying to figure out why it isn’t as successful as it used to be. The lack of direction, in this case, is as much the fault of the predecessor’s lack of communication as it is the successor’s lack of vision.

As your business changes, you’ll find a need to add new functions. Your list of functions and functional areas is a living document, with functions being added and dropped over time as needed.

A sample enterprise-level hierarchy of functions

The following sample framework hierarchy is a simplified example of what an enterprise-level functional framework might look like. I didn’t even attempt to list any business functions, for reasons that will become clear when we discuss the business domain.

This sample functional framework includes many IT enterprise-level functions that are common enough across all industries that they should be meaningful and relevant to your organization. Again, this is just a sample, not to be considered complete in either breadth or depth. Remember to keep it simple. The goal is a napkin drawing, not a Where’s Waldo poster.

This sample represents a perfect world where you don’t have to worry about legacy architecture that doesn’t function the way you would like. The functional framework is always conceptual. The real world details will, for the most part, be embedded in the governance documents, not visible in this functional framework.

Maybe all your development is outsourced – you don’t own custom software development. Maybe all your software is “black-box” and you have no opportunity to manage data directly – you don’t own that function. Maybe your hardware is all a cloud-based service – not a function you support. Regardless, these functions are occurring somewhere. You may not have a lot to document, but you’ll still have policies that those who manage the outsourced functions for you will have to adhere to. You’ll have standards (i.e. service level agreements), and you’ll need to document roles and responsibilities. Many of the processes are completely outside of your responsibility. However, some support processes apply to that external work.

If I were working with a company to develop a functional framework for their organization, this sample framework is where I would start. On the IT side, what do you do that can’t be described as one of these functions? I would expect there to be a few things that need to be added, but I would be very surprised to find that this basic functional framework concept couldn’t easily be extended to include those functions. Again, the business functions in this framework are typically only those where active architecture and governance is still being developed. Even though this whole functional framework is focused on the business, when you’re initially building out your framework, only worry about the existing IT functions you already provide for the business. You aren’t ignoring the business – you’re documenting what you already do for the business. That’s still business-focused, if done correctly.

This functional framework isn’t intended to be a mandate to which your enterprise must comply. It’s included as a sample to help make the concepts clear and to give you some ideas about things you might want in your own framework. In this function framework example, I’ve included hardware and software services as separate functional areas as a common example of how you may wish to tweak the framework to meet the unique environment in your organization. These are discussed in more detail within the individual domain chapters later in this book.

A sample department-level hierarchy of functions

Of course, architecture and governance should be performed at the enterprise level. A company of any size and complexity that has no enterprise architecture and governance initiative is almost certainly well on its way to becoming overwhelmed by the complexity of the IT functions it needs to manage, not to mention being in significant danger of regulatory non-compliance.

If you don’t have the power to make architecture and governance happen at the enterprise level, you can still find value in using a functional framework to manage the areas of the organization whose functions you do control. In a sense, your department is operating as if you were an enterprise with a lot of outsourced functionality.

Perhaps you don’t manage the hardware or the network you use. That’s not too different from a company that outsources servers to a third party cloud-based virtual server hosting service. In fact, I think we can all see the day where many of the function we have traditionally considered internal will more often be outsourced functionality. The hardware and software used to support the business is increasingly a virtualized commodity.

However, if you outsource functionality, you still have security policies, service level agreements for performance and availability, and processes for getting support when needed. This is true whether you’re a company outsourcing functionality to third party vendors, or whether you are a department outsourcing functionality to other departments.

In essence, the IT domain functions of your department-level functional framework will look very similar to the enterprise example above. The main differences will be the amount and depth of detail that you need to go into when defining the architectural strategy and roadmap, and the governance polices, standards, processes and roles for the functionality that’s outsourced.

For example, if you outsource application development, you probably want to have some governance for software development process, even if the developers are not managed by you, just to make sure that what you consider best practice is followed. The level of detail will be usually much greater if you are managing your own development, rather than managing outsourced development. On the other hand, you may be comfortable with a fairly self-directed agile development process internally, but want a much more formal process for management oversight of external development. Depending on the function, outsourced functionality may require more or less formal management than internal functionality.

The sample functional framework below is for a fictional enterprise analytics department within a larger company. This department is responsible for all data used analytically, including the enterprise warehouse and many application-specific data marts. Because the managed functionality is narrower in breadth, we can go into more detail regarding the functions without losing sight of the big picture. You can go into this level of detail at the enterprise level also, provided you have the ability to collapse the functional framework to a higher level for discussion and general planning purposes. For the most part, in an enterprise framework the lower levels of detail are of concern only to the architects in the domain owning the functionality.

This sample only has three levels of functional hierarchy. Yours may have more, but even the largest of companies seldom really need additional levels of abstraction. Remember that this is the framework on which your functions hang. All your functions need a place on this framework to hang, but each individual function need not be called out. For example, the second detailed task in the Software development lifecycle area of this sample framework is “Project Management.” If you’ve ever been involved in project management, you know it can involve estimates, resource calendars, complex plans, baseline comparisons, and more. The important thing is that all those detail tasks have a place on the framework. The functional framework is only detailed enough to break down the strategy, the standards, and the ownership into manageably small chunks.

Later, when we discuss documenting the architecture and governance of each function in your framework, you’ll find that there’s plenty of room to go into far more detail in the documentation you hang from this framework. Keep your functional framework simple enough for people to grasp conceptually. If you add too much detail at this level, you’ll be back to overwhelming complexity, and you’ve missed the entire point of this book.

Another opportunity you have with a departmental-level functional framework is to group the functions based on management responsibility. Again, functions are not derived from your organization structure. That said, in a smaller department within the enterprise, it’s quite likely that when the dust settles, each function will be owned by a single manager. In your software development process, one manager may own business requirements and testing and another may own change management and operations. As long as the functions were derived independent of your organization structure, there is no harm in grouping them by manager on the framework. Indeed, there’s a good deal to be said for having very clear lines of management responsibility using your functional framework.

Notice that, in this sample departmental functional framework:

• The function detail reflects the focus of the department (i.e. information management).
• The application and technology domain functions reflect that most third-party purchased software and hardware is managed outside the department. The only real management is in the support functions required of the outside area, and the compliance functions imposed by the outside area.
• In this example, I added some business functions to reflect initiatives that are still in the early planning phases, and have not yet become IT supported functions. This will be explained in more detail under the heading Business functions (page 82).

Functional hierarchy summary

Your details will differ from these examples. That’s to be expected, and those differences are perfectly fine, provided your framework doesn’t violate the following core tenets:

• Minimum Complexity. These sample functional framework were trimmed a little for legibility, but your framework shouldn’t be too much larger than these. If yours runs several pages, you have far too much detail. The goal here is to make the functional hierarchy simple enough to swallow, conceptually. If the functional hierarchy is too complex to easily visualize, then it’s going to be too complex to easily manage, and managing IT complexity is the whole point.
• Unconnected to Organizational Chart. There is nothing on these sample functional frameworks about org chart positions. You might look at them and immediately know who in your organization owns some of these functions, but that ownership isn’t mandated by the framework. If you have multiple rows for the same basic function, i.e. “Business Analytics for Department A” and “Business Analytics for Department B,” then you need to merge them. “Business analytics for department A” is more than likely an org chart position and a sure sign that someone is trying harder to protect their personal territory than to help solve the problem of managing IT complexity.
• Not about Architecture or Governance. This functional hierarchy doesn’t contain any functions for architectural or governance. Those will be captured in the cells underneath each function. It’s just a simple functional description of the organization that the architecture and governance will have to support.
• Functions are Verbs, not Nouns. You can’t point to a policy, form, database, application, or server and declare it a function. Those are just objects. A function is something that happens. “Securing Data” is a function – “Database Request Form” isn’t. Admittedly, it is awkward to avoid nouns when they are so pervasive in our industry. However, it is also important to remember that functions are things that happen – not the things that they happen to. In this example, the functional areas are all verbs. Ideally, the individual functions would be also.

Managing functions – adding architecture and governance

We keep talking about architecture and governance. They’re really two sides of the same coin, and should really be considered part of the same program. Governance is how we manage what we do, where architecture is deciding what we should be doing in the first place.

It’s tempting to say that architecture and governance are functions, and add them as a column on the functional framework. This is the main source of confusion behind the meaning and scope of architecture and governance programs. When I talked with those companies11 who were spinning up architecture and governance programs, the common thread seemed to be, “OK, I’m already managing all these IT functions. What is this new ‘governance’ function I’m going to have to do on top of that?”

Governance and Architecture aren’t functions in your functional framework; they’re how you manage those functions.

The most important thing you’re going to do with this functional framework is to create a unified long-term vision for all of your functions. You are going to identify governance policies, roles, responsibilities, and oversight processes for all your functions. You are going to set up a way to create standards, review, and approve waivers, and escalate conflict for all of these functions. Architecture and Governance aren’t something you do in addition to managing IT functions; they are the management of those IT functions. The good news is that you’re probably already doing far more architecture and governance than you realize. Our goal is to organize it, simplify it, and bring it up to an enterprise initiative, not a departmental function.

Two kinds of people – focus on today’s problems versus tomorrow’s

There are two kinds of people in this world – those who are solving today’s problems and those who are solving tomorrow’s. You definitely need both kinds.

It’s considered poor practice to have an architect as a lead developer on a project. Similarly, the manager of developers shouldn’t also manage operations. It’s extremely difficult to multi-task when the tasks are at different planning horizons. Absolutely the worst case example is when the same person is tasked with working on the 3-5 year horizon strategic architecture, and also tasked with supporting daily operations. I find this is most often the case where architects also function as system administrators.

In every location I’ve worked, there’s been at least one architect who struggles with achieving the three-year planning horizon mindset. Even if they don’t have actual responsibility for shorter-horizon tasks, their eyes keep drifting there. Perhaps it’s the result of the roles they’ve come through in their career path. Perhaps it’s a natural inclination for more immediate gratification. Regardless, these architects seem to always push for short-term expediency over long-term efficiency.

In my experience, a lot of friction within architectural teams is due to this very conflict. It’s not that one of the architects is intellectually inferior, but rather that they keep reverting to a shorter-term planning horizon. In most cases, the architect keeps dropping to project-level planning horizons. This is where their vast experience has trained them to operate. Those same skills at delivering projects that have led to their rise to the architect position they hold today are now interfering with their ability to function in that role.

Even worse, I’ve had architects with an operational mindset who just want to be able to step in where there’s an issue and make quick decisions. It’s much easier to ride in like a knight on a white horse and save the day in the operational arena. In the long-term strategic planning arena, the battle is more of a marathon, and the victory and vindication can be a very long time coming. Some people just aren’t suited to that kind of delayed gratification. It’s difficult for these people to step away from the knee-jerk reaction to immediately apply their knowledge and experience to every immediate problem that comes up, and focus on the long-term problems.

Every project is going to be a compromise between the long-term ideal and short-term return on investment. In order to have those conversations and weigh the various choices at the project level, architects first need to articulate a vision of that long-term ideal future. The time for the compromise is not while creating that vision, but when working at the project level to guide individual projects toward compliance with the future vision. Inevitably, some people given an architect title will tend to design a strategic vision that has many short-term compromises built in because their experience tells them that these compromises will be needed. That tendency to compromise doesn’t mean that these people are less valuable resources, but they may be misplaced resources. The same person who makes a second-string strategic architect may make an outstanding project-level technical lead. You need both roles.

Growing up, I was a big fan of the original Star Trek series. The crew of the Enterprise included Chekov, the navigator, and Sulu, the pilot. Have you ever thought about those two roles? Both involve flying the ship around, right. Why did they need two of them? What was the difference?

The difference is that the navigator sets the ultimate goal and the flight path to get there. They “lay in the course.” The pilot, on the other hand, steers the ship around local obstacles, making sure they don’t scratch the paint. The navigator is focused on the long range, and the pilot is focused on the short range. Both are critical occupations, neither one “better” than the other. It would be a mistake to put the hotshot pilot in the seat that’s responsible for long range planning – a waste of their skill and experience just as much as it would be to put the navigator in the pilot’s seat.

It’s hard to tell ahead of time whether someone would make a better navigator or a better pilot, a better strategic architect or a better technical lead. However, when you do find that someone is misplaced in either direction, you need to make every effort to get them into a role where they can be successful and contribute the most value to your organization.

It isn’t uncommon at all to have a full team of people with the word “architect” in their job title, and little or no strategic planning ever getting done. Instead, they’re focused on the present, creating asset inventory lists, discussing production problems and active projects, not focused on the architectural horizon. Of course, you need people focused on both long range and shorter-range horizons, but not the same people. If you have architects who can’t tear themselves away from shorter horizons, maybe those people should be moved back to positions where their skills and inclinations are needed. Then you can look for someone else to fill the architect positions.

Speaking for myself, I came up in the development track before I moved to an architect position. However, even as a developer, I was always the guy saying, “If they’d only asked me…” Every single promotion I’ve ever received has been the result of someone getting tired of listening to my suggestions, and giving me a chance to prove myself. If you can find a senior resource who really knows their trade, knows your infrastructure, and is always casting a vision for the future, citing industry pundits and sketching napkin drawings, you may want to consider them as a candidate for a strategic architect.

Architecture

Architecture is how you manage the future. “If you fail to plan, you plan to fail.” No amount of day-to-day management oversight is going to fix your IT issues if you don’t know what you are trying to achieve in the long term.

When there is no vision, the people perish.

Proverbs 29:18

There are two parts of architecture. The first part is creating the strategic vision. If you were to look into your crystal ball and see three to five years into the future, what would you want things to look like? Paint the picture of that future in your strategy documents.

The second part is creating a tactical roadmap from that vision. If you want your disaster recovery function to look like your ideal strategic vision three years from now, what are the steps that must be taken each year?

You aren’t documenting a utopian ideal. It’s probably unrealistic to plan for a future in three years where all of your legacy applications with their functional limitations will be replaced by high-end, state-of-the-art products. That sounds more like the vision of the IT purist rather than the vision of an architect trying to support the business in the most efficient, productive way! Odds are that the limited budget you are going to have could be better spent in other areas. This reminds me of that childhood classic, “It’s the Great Pumpkin Charlie Brown,” where Linus talked Lucy into waiting in the pumpkin patch with him to see the Great Pumpkin rather than going door to door with the other kids. At the end of the movie, when all they saw was Snoopy, Lucy cried out, “I could have been trick or treating!” Don’t let IT invite the business to the pumpkin patch if their time and money could be better spent trick-or-treating. Focus on what’s important to the business, not the IT Great Pumpkin.

For some functional areas, you’ll find that your solution is mature, and barring any major industry changes or breakthroughs in technology, the future has already arrived. Great! Document your architecture and check off the box.

For most other functional areas, your current solution is not all that it could be. Document your strategic vision for the future, and document the steps that it would take to get you there. You may not even know all the steps, but document the steps you do know. Each year when the budget cycle begins, you’ll have a list of all the things that you need to accomplish in the next year to reach your eventual strategic vision.

Of course, each year both the strategic vision and the tactical roadmap will need to be revisited. Other business goals or regulatory requirements may need to be prioritized, pushing the strategy out. That’s fine, so long as both the long- and short-term implications of the decision are carefully considered. The future is a moving target! Keep adjusting your aim.

Building and maintaining this strategic vision and tactical roadmap are very important responsibilities of your EAG architects and involve significant time to research, discuss and document. When the architecture program is first launched, you can’t expect to sit down and write the strategic and tactical architecture plan for every single function. You may, in fact, never get to some of them. You will need, as an EAG team, to examine the gaps in your framework and assign them out in the order that makes sense, based on their potential impact on the business. Remember – it always comes back to the business. Where is a long-term architectural vision and strategic roadmap going to provide the most value to the business? Work on that one first.

Through an acquisition, I once ended up working for a large company that was in a growth market. The company had been founded from the very beginning as a consolidation of eleven different child companies. The internal architecture was appalling, a significant drain on expense and productivity, and everyone knew it. However, rather than addressing the architectural integration issues, the business decided (rightly, in my opinion) that they were facing a rare growth opportunity, and elected instead to invest in growing their customer base. They knew that they would eventually have to turn internally and reduce the expenses resulting from poor architecture, but they consciously elected to postpone that for about four years to take advantage of the growth opportunity. I chose not to wait out those four years, but I’ve often pondered how we would have tackled the project, given the chance.

Strategic planning

What is a strategic plan, in the context of a functional framework? It’s a picture of what you want your IT infrastructure to look like in the future, together with a description of the value to the business of such a vision.

The strategic plan for your company needs to be broken down into manageable pieces. At the highest level of abstraction, you don’t want some massive “city of a thousand planets.” While that vision may be beautiful, it’s too complicated to manage unless you break it down. Remember, the whole purpose of what we’re doing is to manage IT complexity on behalf of the business. So break that massive world-vision down into separate visions for each of the IT functions in the list you built earlier.

In some cases, the different functions are tightly integrated, and it might be tempting to create a single strategic vision for both functions together. Avoid that temptation as best you can or else admit that they aren’t separate functions, but rather sub-functions of one higher level functions, and arrange your functional framework accordingly. A good example is the software development lifecycle (SDLC). There’s really one long process flow consisting of project initiation, requirements gathering, design, development, and testing functions. If you think ahead to when you’ll be writing the governance process documents, you know you don’t want your SDLC processes spread across a dozen or more function documents. You’re going to want a single document for all the SDLC processes and roles. That’s fine for process documentation, but at the architectural strategy and roadmap level, you need to keep the functions separate: a strategy for the testing function and a separate strategy for the change management function, etc.

I’ve found this to be a good practice. Functions can be combined once you reach the governance documentation, but it always seems best to keep the architecture for each function separate. You can have the strategic plans for multiple functions in a single strategic plan document, as long as each function has a distinct and separate strategy spelled out in that document. They are still separate strategies, even though they are collected into a single document. The Appendix contains a sample template for capturing both the architectural strategic plan and the tactical roadmap.

The strategy doesn’t have to be in detail, but it does need to be recognizable. You don’t have to name specific vendor products, but you do need to name the components with vendor agnostic labels that identify the component’s purpose. Your plan needs to contain more than vague future wishes for an IT function: “It will be faster,” or “It will be more scalable.” If you don’t know how you are going to approach making the function faster and more scalable, then you don’t yet have a strategy. The strategy needs to be clear enough to guide future decisions in the right direction without being cluttered up in design details.

I’ve heard of some major manufacturers who claim to have fifty-year strategic plans. Maybe that’s possible on the business strategy side, but I think we would all agree that it would be a waste of time to try to predict what our IT infrastructure will look like fifty years from now. IT capabilities change far too rapidly. If you have a solid grasp on the plan for the next five years, you may want to expand your IT strategic planning out to eight or ten years. However, you had better have a better crystal ball than mine! Most companies have been pretty much winging it strategically up to this point, and just being able to plan your IT infrastructure three to five years down the road is plenty to take on for now. Even that much vision will create significant strategic advantage for your business.

IT is incredibly complicated, but it has the power to transform the business, making a real difference in people’s lives. It’s changing the human experience, and we get to be a part of it! The opportunities for architects today are unprecedented. With that power, though, comes great responsibility. We are casting the vision that will steer the business into the future. Our architecture is the star that steers the IT functionality of the entire company through the rough waters that lie ahead!

One critically important part of each long-term strategy is to document the business case. Why is this so important? Is the strategy “good for the business,” or is the strategy merely a desire for architectural purity, or the desire to play with the latest IT toys, regardless of the return the business will receive from the investment? You need to document the business driver stating why this vision of the future will benefit the business, justifying expense.

Unlike the business return on investment (ROI) that we’ll discuss in the tactical roadmap, the business driver for the strategic vision can be fairly generalized. The driver isn’t a dollar amount; it’s just a description of how this vision benefits the business. “Increased customer satisfaction and reduced churn.” “Expense reduction through resource consolidation.” “Significant reduction in risk of a security breach.”

IT architects will be tempted to skip the business justification as self-evident, and jump straight to the fun of shaping the vision for the future. You can’t skip documenting the business justification. If you can’t articulate in a very compelling way why the architectural investment will benefit the business, then you’re just playing games and wasting time. This is a business, not a science project.

Tactical roadmap

The other half of architecture is the tactical roadmap. As Arthur Ashe once said, “Success is a journey, not a destination. The doing is often more important than the outcome.” IT governance demands an architectural destination. But real business value is realized through the tactical roadmap journey. The vision isn’t an IT project and won’t generate business change. The tactical roadmap is how change happens. It’s where the rubber meets the road.

The strategic plan is a vision for where you want to be in three to five years. Unless you’re pretty close to that vision already, though, it will be hard to know what steps you should be taking. This is where the tactical roadmap comes in.

The tactical roadmap consists of a series of cycle objectives, which represent the steps you need to take in each of the foreseeable budget cycles. For each budget cycle, you’ll list the objectives that need to be funded, and how that business investment will be justified.

Say you have a vision that all your inter-application operational communication will be based on web service calls within five years. Your strategic plan will paint the picture of what that world looks like, what the pieces are, and how they interact. It will articulate how that vision of the future will benefit the business.

However, you aren’t anywhere close to that today. You have a few ancient applications that have no SOA interface, you don’t have an enterprise service bus (ESB), or more than a handful of point-to-point services. That vision is a long way from where you currently stand.

No problem! Just break the vision down into steps. This is what software programmers do, right? Break big, complex problems down into lots of smaller, easier problems. There are two ways of approaching this, and you’ll need to do both.

Justifying tactical IT projects

The first way to break down the vision into steps is to make year-by-year goals as best you can without knowing what the business will have you working on. If you were guaranteed a moderate budget each year, what would you do first that would bring immediate business value while taking a step toward the long-range goal? What would you do after that?

You might start with a first year goal of taking what’s currently a nightly batch file transmit of data between a source system and a call center solution, and replacing it with a handful of point-to-point data services. That would reduce latency, reduce disk usage, reduce the risk of data breaches, and reduce the chance of the call center application using the source center data inappropriately, because the data owners would now be in charge of filling the data request.

I once worked for a major telco where the customer information in the call center and the customer information in the store POS were separate repositories, synced nightly in a batch process. One day a married male customer of ours was allegedly caught cheating on his wife. He immediately called our call center and changed the PIN required to access the history of all the calls made from his phone. About four hours later, his wife walked in to a retail store, gave the salespeople the old PIN, and had them print out all the available call history detail. Our company ended up paying the husband’s divorce settlement because we had inappropriately given access to the information critical to the judgment against him. That one mistake cost more than it would have required to make the infrastructure changes necessary for both the call center and the store systems to share access to the same single copy of customer information. This wasn’t just some internal IT science project that IT was asking the business to fund; this was a priority for the business, affecting both real expense dollars and the company’s reputation in the marketplace.

So, if replacing that batch synchronization with real-time lookup services is your roadmap for year one, then the next year you might want to call that same data services from another source application, and, now that you have a service that’s called by two enterprise-critical applications, invest in a starter Enterprise Service Bus (ESB).

And so forth. Figure out how big of bites you need to take to get the vision implemented in the timeframe you have planned. Just remember that each year’s goals must provide incremental business value to justify that year’s expenditure. You’ll occasionally find visionary business leaders who are willing to invest large dollars over multiple years, on faith that spend will eventually result in value. However, this is rare, and usually only after you’ve proven yourself on several single-year projects.

Most businesses can be convinced, if you’ve done your homework and documented the potential return on investment (ROI), to lay out some cash on faith that you can make a difference, but they will want to see that difference within the same fiscal year, before you come asking for more money the next budget cycle. Rarely, you might be able to go two years, but don’t count on it. You have to make each year’s budget count for the business. This is why we use a year-by-year planning increment in our tactical roadmap, to coincide with the budget cycle.

Hijack business projects

The second thing you’ll do to progress your strategic plan is to carefully watch what projects the business requests each year. You may not get advance notice on these. If you’re quick on your feet, though, you can find projects that the business really wants and are going to fund anyway. You need to make those projects take your infrastructure a small step toward your strategic goals in a way that won’t break the ROI for the business initiative.

This is important, and the key to a long-lived, productive enterprise architecture and governance program. Many EAG programs produce a long list of internal IT projects that set lofty IT-centric goals and are shocked to find that the business isn’t excited about funding them. An IT-centric EAG program is seen as a drain on the business, taking money away from what the business wants to accomplish. On the other hand, an EAG program with a comprehensive vision for the company’s future, that is willing to work within the constraints of existing business initiatives is seen as valuable to business.

I once presented this functional framework concept in a breakout session at an industry conference. On the last day of that conference, a Gartner industry analyst gave the keynote speech. In front of the whole conference, he called my name and asked me to stand up. He told everyone that he had attended my presentation, and wanted everyone to share his takeaway about hijacking business projects. I was very flattered, of course. I would love to have talked with him about his thoughts on the rest of the functional framework, but I can say that he was definitely an enthusiastic supporter of the idea of rolling out your IT vision within business-funded projects.

Seriously, this may be the single most important concept in this book. Hijacking business projects is far better than asking for business dollars to fund an IT agenda. A good architect must have a bit of pirate in their blood.

Perhaps there’s a business request for a new customer portal, or for new functionality in your customer service application. As long as you’re going to have to design and develop new functionality, you might as well make it comply with your long-term service-oriented strategy, right? Maybe the project can’t afford to implement a full ESB, but you can start creating point-to-point services and take a small step in the right direction while working on the things that are most important to the business. That’s better than letting the project take steps in the wrong direction, taking your infrastructure further from your strategic goals. Enough small steps and you’ll eventually get there.

What about the things that IT wants to do but aren’t real business priorities? Guess what? If these things aren’t important to the business, you shouldn’t be focusing on them! Now, that said, there are times when there may be technical issues that should be important to the business but they don’t yet realize it. In those cases, it’s your job to convince the business of the impact. If you can’t convince the business of the priority of these pet projects of yours, then you need to reconsider your own priority and timeline. The business doesn’t exist to fund IT projects; IT exists to support the business. You work for them, not the other way around. Your job is to support business priorities, not to go off on your own, taking business dollars away from the things that are important to the business.

The difference between these two approaches is that the first are IT-generated projects, while the second are business-generated. Even though the IT-generated projects are justified by an estimated ROI, those projects aren’t necessarily aligned with the primary goals of the business for that year. You’ll have to work hard to justify money for each one of them because with the limited resources available, every IT project reduces the amount of resources available for business projects, reducing how much value you are bringing to the business, in their opinion.

Therefore, if you can catch those real business projects and tweak their approach just a little bit, you’ll have a lot more success reaching your strategic goals. Rather than being seen as a drain on business resources, you’ll be seen as a valuable partner who adds value to important business initiatives.

An architect can, to some degree, be blissfully ignorant of the real world when creating the long-term strategic vision. In fact, in many cases it helps to be just a little blind to the reality of internal politics and sacred cows. After all, the cost of building of the long-term strategy is mainly limited to the architects themselves. The strategy is just a vision, not a real project. The long-term vision costs the business very little.

However, when it comes time to create your tactical plan to implement that long-term strategy in real-world projects using either of the approaches above, you need an architect who has deep experience in the real world of your company. You need someone grounded in reality who knows what’s going to be possible and how big of a task it’s really going to be. Otherwise, you end up with tactical roadmaps that are unrealistic flights of fantasy. This last is very common in organizations where the architects are full-time direct reports of the EAG program rather than matrixed resources with real day jobs.

Every step in the journey must make business sense. At a minimum, you should be able to articulate how the business return on investment (ROI) will exceed its cost within a reasonable amount of time. Ideally, the ROI will be realized within the scope of your planning cycle. If your strategic roadmap has year-by-year goals, then this year’s investment should be realized before next year’s investment is requested.

If at all possible, you should plan on going further and showing why this investment of time, money, and resources will provide more return than any of the other projects the company might have invested in. At a minimum, however, the business case should be shown to at least pay for itself, justifying the resources that are being dedicated to the project.

Naturally, it’s likely that it took most of that fiscal year to design, build, test, and implement the solution, so it’s a little harsh to expect it to pay for itself in the first revenue cycle. You might easily argue that the ROI will be seen in the second cycle instead. As long as the expected ROI timeframe is documented from the beginning and the business accepts that investment risk, you’ve done your job.

Let me present one caveat. When you claim an ROI, you are committing to building a solution where that ROI can be measured. Whatever it is you say you are improving, you need to build metrics into the requirements, along with the appropriate governance controls to ensure that they are collected and reported.

You don’t have to give all of that monitoring detail in the strategic roadmap. Just realize that you are committing to it down the line. Don’t you dare claim an ROI you have no intention of monitoring. It’s inexcusable to claim that the cost of measuring the ROI is too high; that the business should just trust that the investment was sound. If the project was one that was requested by the business, not by IT, then the responsibility to justify the spend with ROI is on the business, not IT (though IT should still build in any metrics required to measure the business’ stated ROI). However, if IT initiated the funding request, then IT must justify the drain on business resources, and must be able to show proof during the next funding cycle that the investment paid off.

Information systems in architecture

One of the key concepts you’ll see throughout this book is an information system. An information system is a collection of people, applications, and technology that work together in a system to create and maintain information. Most of your major applications are going to be considered information systems. An information system is an ecosystem within the corporation that can be thought of as one of the high-level components of the corporate infrastructure.

Each information system has an owner, who should be on the business side, not an IT resource. The business owns the information system and makes decisions about how it will be used and enhanced. The infrastructure supporting the system is owned by IT, but the system function is a part of the business.

Many regulatory bodies require that you maintain a complete list of information systems in the enterprise in order to ensure compliance reaches throughout your infrastructure. This list of information systems and their owners is usually created and maintained by the EAG team.

For the most part, your architecture is performed function by function at the corporate level, not application by application. Some of those functions may indeed be implemented on a single application in the infrastructure, but the focus of the architecture is on the function’s place in the enterprise, not its place within an application. You may have three separate print management systems today, but the strategic vision will normally either be equally applicable to all of them, or will include all of them as separate components in one architectural vision. You wouldn’t expect a separate long-term strategic vision for each application if they perform the same function in the framework.

Governance

Your IT Governance encompasses how you manage IT functions day to day. It’s how you create, document, update, communicate, monitor, and enforce the policies, standards, processes, and roles that will be used to manage your IT functions on a day-to-day basis. Governance isn’t the same as architecture. Architecture is managing your future vision. Governance is managing what’s going on in the real world today.

My first real job was working as a lifeguard. I was well trained and in good shape, but I have to admit I was a terrible lifeguard. Sitting in the sun for hour after hour, day after day, my mind wandered. I was about to graduate from High School and facing the grim reality of a future where I was going to need a real job to pay my own way through life. So, I would get to thinking about things, planning, working things out in my head. I would not be watching the swimmers. I still don’t understand how the other lifeguards were able to stay alert and watchful hour after hour without losing focus. The architect roles plan for the future. The governance roles have to stay alert and focused on what’s happening right now. Having a great plan for the future is no excuse if someone drowns. Your governance people are your company’s lifeguards.

Governance of IT functionality can be thought of as three things: the policies, standards, and the processes and roles you use to manage the IT functions on behalf of the business.

Consider the following example:

• Policy
  • Corporate — “Every network-attached device must have a unique identifier.”
• Standard
  • Desktop Services Standard — “Desktop services will generate a unique identifier for each network-attached device using the asset management system and place an asset tag sticker with that number on the front panel of the equipment.”
  • Data Center Standard — “The manufacturer’s serial number will be used to uniquely identify each asset on the data center floor.”
• Process and Roles
  • Desktop Services Processes and Roles — “All network attached hardware in the workstation environment must be installed by Desktop Services technicians, who will generate and record a new asset id and tag the equipment before removing it from the storage area…”
  • Data Center Processes and Roles — “Before standing up new network attached hardware in the data center, the data center technician will record the manufacturer’s serial number in the asset inventory system…”

Obviously, your actual documentation content will be much more formal, and will contain a great deal of additional information. In reality, the policy above would no doubt include verbiage about regular asset inventory, etc., but this example should clarify the distinction between the various governance document artifacts.

Using a functional framework, the EAG program team can easily produce reports showing the percentage of the IT functionality that is actively managed by architecture and governance. Which functions have been brought under governance? Within each function, which information systems are participating? Which are not? If you want to show the value of enterprise architecture and governance, you must be able to show the degree to which the program has penetrated the business.

Part of the governance program must include:

• Where are these documents located and how are they accessed?
• How often are they reviewed by architects for compliance?
• If the documentation is found to be non-compliant or incomplete, what is the process by which it is rejected and resubmitted, and how is that enforced?
• What is the frequency which they are reviewed by the document author for any necessary updates?
• What is the process for requesting clarification or enhancements to the documents?
• Any governance document has the potential to require exceptions to be granted from time to time. How are those exceptions submitted and to whom? What are the criteria for accepting or rejecting exception requests, and how are those decisions communicated and archived? Is the exception permanent, or for a limited period of time? All of this is part of governance.
• If each information system fills out their own copy of a document, how is it determined that the repository contains documentation for the complete list of information systems? Where is the master list of information systems?

Information Systems in Governance

Policies, as we will see, are very short, straightforward mandates at the corporate level. Policies are never defined separately for each information system . However, other than these corporate policies, all the other governance document artifacts are quite often created and maintained separately for each information system, though this need not be the case. For example, the standards, processes, and roles in the application security provisioning function may be the same for all information systems. In that case, you would probably want to consolidate them and only have one document at the corporate level.

The goal is to minimize duplication, leveraging the same governance documents for as many information systems as possible. Where the governance standards, processes, and roles are unique and different, you should not hesitate to create multiple documents, provided they use the same template and are stored in the same enterprise repository.

In fact, this is a practical way to help determine the boundaries between information systems. If you have a whole suite of individual .NET applications that are all developed using the same processes, migrated through test environments using the same processes, provisioned using the same processes, and supported by the same operational processes, then they can and should be grouped into a single information system, all sharing a single set of governance artifacts.

Executive versus operational governance:

The realm of governance (which includes policies, standards, processes and roles) is broken down into two major components.

1. Executive Governance is where the powers-that-be create, capture, communicate, monitor, and enforce the policies. This is the body that decides how the company will operate. This includes handling requests for waivers or modifications. This executive governance is usually staffed by the enterprise architects, possibly supplemented by executives and subject matter experts (i.e. HR or Legal) when needed. Policies, which are corporate mandates, may also need to be ratified by the executive leadership team, though they do not necessarily participate in the authorship.
2. Operational Governance is where the IT functions are managed day-to-day using the processes and roles that were defined by executive governance. These are the people who execute the process, not the ones who create the process. Several industry authorities12 today refer to executive governance as simply “governance,” and refer to operational governance as “stewardship.”

Executive defines, and operational executes. This isn’t a new concept. COBIT divided the management of IT into four areas, though they gave those roles different names. The terminology you use isn’t important. What’s important is that all of these roles exist, and the responsibilities are clearly defined and documented.

In their capacity of creating a cohesive array of governance documentation defining how the work will be performed, the executive governance team can be thought of as a governance Center of Excellence (CoE), or a Competency Center. They are tasked with creating a body of governance documentation that is consistent across the enterprise, complete in breadth (all IT functions) and depth (policies, standards, processes, and roles). If the creation of governance artifacts is delegated to individual information systems, then those departments become individual centers of excellence.

For example, you might allow the analytics resources to document their own standards, processes, and roles for creating external-facing customer reports. These might include guidelines for font, color scheme, headers and footers, disclaimers, standards for sensitive information, and processes and roles for developing and testing. In that case, the BI Analytics team is your analytical reporting center of excellence. These governance documents will still be subject to review for compliance to corporate policies and architecture, but within those broad constraints, the BI Analytics team operates independently as a center of excellence.

This kind of distributed executive governance is very important to your ability to manage IT efficiently at the corporate level. Your EAG team will not be able to develop all the detail in every governance document. Moreover, if they did and simply handed those documents out as a mandate, they wouldn’t be enthusiastically received. But if the EAG team gives the information system team the basic governance document templates and some training on how to flesh out these templates, granting the team freedom to self-govern within the guidelines of the corporate policies as their own center of excellence, then most teams will be more than happy to build the governance artifacts for you. They will probably implement harsher controls over themselves than you might have handed down, had you the time to write the documents yourselves.

Two kinds of people – micromanagers versus enablers

There are two kinds of people in this world: those that micromanage every little thing, and those who point things in the right direction and turn them loose.

If you’ve been out in the workforce for more than five years, I’d be willing to bet that you’ve seen, if not worked with, manager/supervisors of both types. Some managers seem to think it’s their job to hold their employees under their thumbs. I’ve seen supervisors that want their salaried employees to clock out and back in when they go to the restroom. In general, I find that these same supervisors have no knowledge/ability to manage the work their employees are actually doing, but they are masters at micromanaging the details that don’t matter.

I think this comes down to leadership style and the type of work being managed. If you’re managing a call center where a lot of high-turnover hourly people need to be in their seats answering phones, then maybe you do need to be fairly heavy-handed in monitoring people’s whereabouts. However, if you’re managing salaried professionals working on projects that span weeks or months, it seems rather degrading to treat your employees like schoolchildren.

When I purchased the house I live in now, my wife and I had to go to an abstract and title company to sign all the papers. The person who stepped us through the process was very condescending. At one point, she pushed a page over to us flagged for our signatures. She watched us sign in silent anticipation, and then was delighted to tell us we had done it wrong. She made a big show of tearing the page up into many little pieces, sighing heavily, and printing another copy, which we then signed with our full middle names. Several years later, we closed on a house we were buying and flipping for our daughters. We made sure to ask for a different title company, and were on the lookout for the paper that needed the middle names. However, this person took the time up front to explain the process, and why different forms needed different kinds of signatures. As she handed us each page, she explained what the form was, and what kind of a signature was needed. It was a much more pleasant experience.

I think there are some people who just delight in being “big brother,” managing using fear and intimidation, eagerly waiting to demonstrate their total power. That sounds dramatic, but I swear I have no other explanation for the behavior of these IT management “brownshirts.” If I were their employee, as soon as I could find a different job, I would. The better I am, the sooner you’ll lose me, leaving you with a team of beaten-down, low-skill, low motivation employees. There are very, very few times when that sort of management style is appropriate.

Other managers are true leaders. They cast a vision and lead by example. They encourage their employees, and trust them to do their jobs. Yes, they’ll occasionally find someone not pulling their weight, and if a private chat doesn’t fix things up, maybe that person needs to be let go. However, you don’t address the one person who’s slacking off by cracking the whip over the entire team. If you extend trust and someone on the team betrays it, then you don’t want him or her on your team. Your job as a manager is to build a team, not a slave labor camp.

Our job in an EAG program does include the creation of some rigid rules. However, most of the time what’s really needed is a vision. If the people using your policies, standards, processes and roles understand the overall vision, odds are they’ll do the right thing. If they won’t, you need to let them go. Our role isn’t to be Big Brother, laying down the law and cracking the whip. If you have people on your EAG team who like to use that approach, get rid of them, no matter how good they are. Instead, put together a team that will make “the right thing to do” easy to understand and easy to accomplish. Most people who have to perform these functions will do the right thing if they know what it is. Most of the rest of us are just lazy and will do the right thing if you make it easy.

If you want to make the management of IT functionality simpler and more efficient, don’t set yourself up to be the governance dictators. Make the right thing to do obvious and easy, and you’ll be a lot closer to IT functions that seem to manage themselves. What’s really going on is that you are distributing ownership of the IT management to your team, making your own job easier.

Policies

The first governance row in our functional framework is for policies. A policy is a rule that the company wants to enforce. Individual information systems may take different approaches to comply with the corporate policy, but comply they must.

Standards, processes, and roles may be defined at the corporate or the information system level, but policies are always defined at the corporate level. Governance policies (i.e. security mandates) defined at the corporate level should apply to all information systems. If they don’t they’re not polices. Other layers of governance, though – the standards, processes, and roles – can be defined system by system.

If you find that you can’t generalize policy verbiage to the entire organization, then it probably contains too much detail. Standards and processes must support the corporate policies, but you may allow different departments to create their own custom standards and processes, so long as they document and publish them in a consistent manner, and so long as those custom implementations don’t violate the corporate policies.

The policies will largely be written by the EAG domain architects working with subject matter experts such as HR or legal. These policy documents will often contain a verbatim copy of regulatory or compliance verbiage. You should consider creating global templates for all the governance documents: policies, standards, processes, and roles, so that all the various artifacts are consistent in style and complete in scope. You can initially populate your framework with pre-existing artifacts, but you’ll eventually want to convert them to comply with the enterprise standard templates. I strongly recommend you engage a technical writer to develop those templates and manage the document repository where the governance artifacts are stored. I also suggest you examine the COBIT standards before trying to re-invent the wheel. In many cases, enterprise architects are also information system resources, and may also be writing those departmental standard, process and role documents while wearing one of their many hats.

Corporate policy documents are a compliance requirement for many standards and certifications. As stated previously, auditors are used to hearing companies speak in glowing terms about their policies, standards, processes and roles, but will always want to see the actual documentation.

A sample template for corporate policies can be found in the Appendix. It contains the following:

• A header that identifies the location of the policy within the functional framework. It specifies the function area, the relevant function within that area, and the policy name for that function.
• A purpose statement that describes what the policy is intended to do (i.e. names the regulatory requirements or business decisions it supports).
• A scope statement that describes what parts of the company’s assets and staff are subject to the policy.
• A detail section that each requirement in the policy.
• A timeline section that describes when the policy will take effect.
• A section describing how to ask questions and request exceptions.
• A section describing how compliance will be monitored, by whom, and what measure is considered acceptable.
• A section describing the consequences of non-compliance. This refers to the consequence to the employee who violates the policy, not the consequence to the company.
• A communication plan describing who will be responsible for giving training, and who needs to receive the training, and how often.
• A revision cycle section explaining who must review the policy, how often it must be reviewed, and who must approve changes.
• A footer section giving contact information and revision dates.

I wish I had time and space to go into each of these sections, but, to be honest, most of them are pretty self-explanatory. But I do want to take the time to stress the importance of the compliance monitoring section, because I find that’s an area where many EAG programs fail to provide the value they should. There are several different models for measuring the maturity of a process, including COBIT, which we’ve already discussed, and CMMI (Capability Maturity Model Integration). All of these maturity models align very closely, as shown in Table 2.

You can see that these various maturity models are very similar, almost identical. Looking at this table, it should become evident that some sort of automated outcome measurement is required for mature governance. You must build that measurement into your template, so that you measure compliance by default, not by exception.

In order to do this, you need to define the metric, how that metric is measured, and what the acceptable measure is. The metrics should be chosen based on the value to the business, not purely on their adherence to an IT ideal. You may have some metrics that seem more operational, such as compliance with service level agreements (SLAs), adherence to privacy and security policies, and data accuracy, integrity and completeness, but, since every operational policy and process is intended to provide business value, even these operational metrics should be relatable to some business value, albeit indirectly. If they provide no business value, why are the policies in place? Business value may come from many different aspects, including minimizing exposure to penalties for regulatory compliance, reducing fraud risk, expense reduction, improving the efficiency of an operational process that provides business value, increasing revenue, or increasing customer satisfaction.

For example, suppose you create a policy to eliminate redundant physical copies of customer information outside your Customer Relationship Management (CRM) system of record. In this case:

• The metric is the number of copies of customer data.
• This number might be measured using automated tallying of the extracts that are distributed (pushed or pulled) from the system of record, assuming that each extract will be physically instantiated somewhere. There are much more sophisticated ways of detecting data propagation, but this approach will suffice as an example.
• The acceptable measure in your environment at this time might be four: the operational system of record itself, a copy in the analytical data warehouse, a copy sent to a government-required reporting agency, and a copy in a commercial campaign management system that does not have the ability to integrate with the system of record at this time.
• The actual measure may be more like twenty or more.

Remember that you can’t manage what you don’t measure. If your policies don’t include a description of how you’ll measure compliance, then you probably won’t mature beyond level three in the model shown in Table 2. That doesn’t sound like an EAG team that’s on top of their game.

Here are a few guidelines for your policy metrics:

• Your metric should measure something that has real business value, not just an indicator of architectural purity.
• Your policy should state not only what is measured, but how often and where the measurements are to be stored. In order to monitor compliance at an enterprise level, there must be consistent, automated, and centralized collection of data.
• Your metric should be SMART.13 SMART is an acronym developed back in 1981 by George T. Doran14 giving guidelines to designing good objectives:
  • Specific. The metric should be very clear and unambiguous data point that indicates progress.
  • Measurable. The metric should be something that has an objective value.
  • Assignable. The policy should identify who is accountable for the metric being collected. The other roles should be detailed in the process documentation.
  • Realistic. The metric must be something that can be realistically collected, without undue resource cost.
  • Time-Related. The policy must specify when and how often the metric is to be collected.
• Choose your measures to show ongoing value. Governance is a program, not a project. It has no completion date. Don’t choose metrics that imply that it does.

When creating policy documents, keep in mind that every policy is a business policy. Whether or not you will comply with regulatory guidelines is a business decision, not an IT decision. Nike released the Air Jordan sneakers on September 15th of 1985. On October 18th of that year, NBA Commissioner David Stern officially barred Michael Jordan from wearing the shoes during games because the red-and-black shoes didn’t match the color scheme used by the rest of the Chicago Bulls. Jordan was fined $5000 a game, which added up to $410,000 in fines over the 82-game regular season. This was almost two-thirds of Jordan’s $630,000 salary. Nevertheless, Michael Jordan continued to wear the shoes, and Nike reimbursed him for every fine, because the media controversy acted as free advertising, generating millions of dollars in revenue. Most of the time, your company is going to want to comply with all the relevant regulatory guidelines, but there will still be cases when the business may decide that non-compliance makes more business sense. Even security policies are, in the end, business polices, not technical ones.

In some cases, corporate policies require other subject matter experts to approve waivers and modifications and perform regular reviews. Your legal department will need to review compliance policies. HR will want to review any policy for which non-compliance can result in termination. There will be modifications, and the policy document should make clear who all will need to review any changes, a list which should include those other subject matter experts. All governance documents are living, breathing artifacts that will require maintenance and review over time.

Standards

Standards can be defined at the corporate level (i.e. which fields are considered PII), but are more often at the information system level. As long as each information system’s standards support the corporate policy, this is perfectly acceptable.

If you don’t want to allow this departmental flexibility, then, by all means, spell out in a corporate standards document what the corporate mandate for all departments will be.

The Standard templates section of the appendix contains a template that assumes that each function in the framework has a separate standards document. In the software development lifecycle functional area, this means a separate standards document for application design, application testing, and change management.

This function isolation isn’t required, but is a good idea for standards, as it helps prevent the creation of huge, overwhelming documents. For the most part, any one standard applies to only one function. Furthermore, most resources will only be working in one or two functional areas. Our goal is to make IT functions simpler to manage, and separating out the standards by function makes them much easier to work with, provided they are all easily accessible in a repository whose structure aligns with the functional framework. That said, if you’re starting from nothing, you might initially keep the standards for each function as separate sections in a single document per subject area just to prevent the creation of dozens of small documents. As soon as they begin to grow unwieldy, however, I would break them into separate documents by function area.

When you first put together a functional framework, you’ll no doubt have many existing standards documents for many different functions in many different departments, using many different documentation styles. Your first step is to collect those artifacts and get them into the architecture and governance documentation repository just as they are. All of those separate documents should be retained in the document repository, of course. Each standards document should contain all the standards for that function. If a COBOL developer need to research design standards, there should be only one document they need to read.

Therefore, it is appropriate to identify these standards by the framework function, or even by information system. However, that’s the smallest level of granularity that should be acceptable. If you decide to create a separate standards document just for the application design function within the larger software development lifecycle, and you decide to create one application design standard for the Java information system development, and a different application design standards document for the mainframe COBOL information system development, that’s perfectly fine.

Once you collect all your existing standards into the EAG repository, your next goal will be to make the EAG repository copy of those documents the system of record, deleting them from their previous location. In order to accomplish this successfully, you will need to be able to convince the current document owners that they can still manage the document. Authorship will still be theirs. The only thing that’s initially changing is the location of the document. The only oversight that will be imposed is a review by the relevant domain architect to make sure that the standards do not violate any corporate policies or best practices. If the architect reads in a document that passwords are passed as parameters in unencrypted service calls, they will likely push back, changing the standard to comply with corporate policy. In cases like this, change the standard immediately. Identify which existing applications violate the revised standards, and bring them into compliance. It may be necessary to grant temporary, limited-time waivers until the changes can be made, but the standard document should be changed immediately. This review and approval process can’t begin until the documents are in the managed EAG repository.

Your third goal is to convert any pre-existing standards to the consistent enterprise standards template. A technical editor is probably the best person for this job. Converting to the new template does make all the standards more consistent in style, but, more importantly, it makes them more consistent in scope and completeness.

As a rule, your standards will include definitions of IT-centric terms and logic. Definitions of business terms belong in a data dictionary component, which is part of the data quality function of the Information Domain.

Processes

Your processes are the documentation for what you do (or should do) every day. The process documentation should describe the flow of tasks and the conditions under which the process advances or retreats from task to task.

Write this process documentation so that it can serve many purposes:

• The process documentation serves to document the duties and responsibilities for each role, and should be useful for onboarding new resources, reviewing HR job description accuracy and resolving ownership disputes.
• The process documentation should include information about how to handle exceptions, especially emergency production issues. Who has the authority and responsibility to do what? Moreover, what must be done afterward to review or approve the fix as permanent?
• The process document should serve to document your process to auditors. It could include, for example, your CMMI or ISO 9000 certification, or proof that your security initiative is foundationally integrated into your entire process. If a process is intended to support specific corporate policies that should be explicitly spelled out.
• The document should identify the author and the roles that must review the document on a regular basis and who approve any changes. Processes tied to regulatory compliance should be reviewed annually. Who is responsible for the review, and how/where are the results tracked?
• If a situation arises where an information system is not going to be able to comply with the process, how are waivers requested? Where are the approvals/rejections documented?
• You can’t manage what you don’t measure. The process documentation should explicitly define what metrics are needed to measure the effectiveness of the process, who is responsible for collecting them, where are they stored and in what format, and who is responsible for reviewing them. Metrics may measure the maturity of the process, and they may measure the ROI of the cost of the process provides the business. This includes contractual service level agreements, both for services that you provide to your customers, and for services your vendors provide to you. If there is a service level in a contract, your process needs to make explicit how it is measured, who is responsible for getting it done, and what is done with those measurements.

Bear all this in mind when building your process documentation templates.

Roles

It’s critically important to your governance program that you clearly document the all the roles in each process. You’ll find that it’s often going to be the case that everyone will easily agree on what needs to be done, but bloody political battles await the person who dares say who is going to be responsible/accountable/consulted for that work. A failure on this task pretty much guarantees a dysfunctional, unsuccessful organization.

In addition to formal written documentation, it’s usually helpful to include a visualization. This often takes the form of a “swim lane flowchart” showing how the various tasks fit together into the larger process, with a “swim lane” for each role. The flowchart, however, typically only documents the role actually doing the work. The written documentation should go into more detail, spelling out the responsibilities of all the roles.

You may recall an earlier discussion of the distinction between executive governance and operational governance (see Governance, page 58). All of these roles should be included in the process document.

Make sure you name the role, not the person. You don’t want to have to change your documentation every time an individual person changes roles. If a person wears many hats, they are probably performing many roles, and they should document each role separately.

There are several standards for documenting roles and responsibilities. You’re welcome to use any method you like, so long as each role and its responsibility are clearly articulated. For myself, my “go to” standard for documenting roles and responsibilities is the RACI method developed by those COBIT gurus. Using this methodology, you would include in each task of your process the following roles:

• Who is responsible for actually doing the work? Depending on the task, this may be a developer, an analyst, a call center operator, or an executive. This may be more than one individual.
• Who is accountable for verifying that each individual task was completed correctly? The testers are not accountable for the development task; they have their own task in the process. Accountability for any given task should be assigned to only one role.
• Who must be consulted as a subject matter expert, although they may not actually be responsible for doing the work? This is two-way communication.
• Who must be kept informed (i.e. one-way communication) of the progress and outcomes?

There are several variations of this standard to accommodate the need to document unique and unusual responsibilities such as:

• Processes where multiple approvers have veto power over a task
• Processes where some roles must explicitly not be informed about the task progress and outcomes, such as blind study research trials
• Processes where other roles may assist the role primarily responsible
• Processes where additional roles are required for quality or testing responsibilities

I encourage you, however, to keep your roles as simple as possible. The goal here is to simplify the management of IT functions. Don’t create roles just to match an org chart if those roles needn’t be called out separately. Yes, you may have teams to test user interface compliance, security compliance, or other functions. However, you should list those as responsible roles on separate testing tasks in the process, not some new role in the development task.

There are several ways to document these roles.

• You might document the RACI roles within each task in the process
• Alternatively, you might use swim lane UML to identify how the tasks flow from role to role
• Or you might create a single RACI Matrix for all the tasks in your process (see diagram below)

I like to include a swim lane UML diagram showing the process flow, but I don’t think you can use that a technique alone. It’s a great way to visualize the process tasks and roles all in one flow diagram, but it’s used only to document the person who is doing the work. Go ahead and include a swim lane, but make sure to use one of the other techniques to document the other roles in the process. Personally, I’m a big fan of the RACI matrix shown in Figure 2.21.

As you can see, roles are complicated. There are many roles for each task, and many tasks in each process. That being the case, you’ll often find that there is a high-level role accountable for each process as a whole, a process owner. Various roles may be accountable for the different tasks in your software development process, but there’s probably one high-level development manager who ultimately owns responsibility for the process as a whole, the owner of the operational governance SDLC process. The accountable roles for each of the functions in the process typically report to this process-manager role, either as a direct report or in a matrixed, dotted line relationship. These roles and relationships role should be documented as well.

You should be able to look through the RACI matrix and see that all the accountable roles report to the process owner. If the relationship is other than a direct report, explicitly spell this out in the process and roles governance document.

It is this manager’s role to oversee the day-to-day operation of this entire process. That process owner must give day-to-day direction regarding relative priorities and tactical decisions to the roles accountable for the individual tasks in that process. If the process manager is going to be successful in managing the operational governance, these relationships must be clearly defined. You are not going to be successful in managing for IT functions on behalf of the business if the team isn’t working together under a single clear vision and reporting structure. You can document the RACI roles for each task until you are blue in the face, but if the roles accountable for those tasks are working under different relative priorities and reporting structures, you’re going to have inefficiencies and differences in priorities, which will lead to disagreements and infighting. Don’t skip this step.

The various task accountable roles need not be direct reports. A matrixed reporting relationship is just fine if the controls are defined clearly. The manager of the application development process may report to the CIO, while the DBA roles actually report up to the CTO. The analysts and testers on the team may report up to the COO. If you can, for a moment, imagine the functional framework with the IT functions subdivided into domains, functional areas, functions, processes, and tasks. Some roles will fall to teams of many individuals. Some individuals will have many roles. The high-level managers can probably look at the functional areas and draw a line around the part they are accountable for. Mid-level managers and supervisors may need to go down to the individual functions to identify their responsibilities. Front line employees will have to go down to the individual tasks within the processes to define their responsibilities. At some level, every person in your company who is supporting these IT tasks in some way should be able to draw a boundary around their area of responsibility.

You are documenting roles, not documenting your org chart. That said, a good org chart should align with the work that’s actually being done. If you find that multiple high-level managers share responsibility for the same IT functions, you should probably rethink either your functional framework or your organization chart. If your company is large enough to have several major information systems all under development, you may have development managers in each system. However, there should be some coordination between these departments.

If your goal were to simplify the management of IT complexity, why would you manage these very similar departments separately and independently? Who is going to make the inter-department priorities and tactical decisions? For example, if one application decides that their test system will be a de-identified subset of production, how is that going to affect the other departments’ ability to perform system integration testing? If your goal is cohesive, comprehensive, coordinated IT functional capability, why would you deliberately choose to make the management of these IT functions isolated and uncoordinated?

Likewise, if you find that one mid-level manager or supervisor is responsible for individual tasks scattered almost at random through the functional framework, you may have an org chart poorly aligned with your work. Wouldn’t it be better for that role to be accountable for tasks or processes that have a similar focus? Operations, security, and change management are all highly formalized processes, all with an immediate focus and no necessary separation of duties. One person can easily manage them. Conflicts arise if the same manager is accountable for all of those functions and software development, which has a longer planning horizon and must be kept separate from operations. This is one reason why it’s critical to create the functional framework as a list of functions performed by the organization, rather than a list of verbs for each position on the org chart.

Most of the high-level processes we describe in our sample functional framework take the form of lifecycles. There is a flow from one process to another through the various stages of the lifecycle. Software development begins with project initiation, design, development, and testing, and ends with production implementation, support, and decommissioning. Each stage of the lifecycle has many tasks. The early stages (e.g. project initiation and architectural design) have relatively long planning horizons. As you move into development, the planning horizon drops to months or weeks. Testing may involve iteration cycles counted in days. Production support deadlines can be counted in minutes.

Wouldn’t it make sense if your organization chart reflected this same flow? Managers and supervisors may be responsible for many tasks, but those tasks are all related, with a similar planning horizon focus and no separation of duty conflicts. I’ve actually seen organizations arrange seating assignments based on process flow so that resources are co-located with other individuals who are working on the same stage in the lifecycle. It sounds extreme, but actually worked remarkably well. Do you think the requirements analysts need to communicate more with the developers, or with production support? Why not locate people to facilitate the necessary communication instead of discourage it?

Defining clear roles using a functional framework prevents political infighting where more than one person believes they should be in charge of the same function. Defining clear roles using a functional framework highlights those functions where no one is really responsible. But one less intuitive way in which the functional framework really helps is in calming the fears that will inevitably occur when you make changes. If you just make an announcement that responsibilities will be consolidated and streamlined, most of your staff will immediately translate this as code for downsizing, and will live in fear that their position will be going away.

This fear can lead to morale issues, obstructionism, and nay-saying. Most people really don’t care about the welfare of the organization as much as they do the gainful employment that comes with their little empire. I’ve found that articulating change using the functional framework helps to give the necessary context, and to clarify the ambiguity of what the future holds. Lay out those lifecycles and show how the responsibilities line up. Usually, many new roles will be created, generating new opportunities, not staff reduction.

I once worked in the enterprise business intelligence organization of a fortune 500 telecom company. When we set aside for a moment the roles and responsibilities we had always operated under and just considered the functions of our organization, it became clear that the functions followed the life-cycle of the work. In that organization, we had business requests that came in and had to be broken down into clear requirements. Next the architects who maintained the strategic vision and standards would look at the requirements and define an approach that guided the project in the direction of our long term goals, then we had developers and project managers who oversaw the work and progress, and we had testing and change management functions to move the work from development to test and into production. And finally there were functions related to post-production support. These functions described the daily work performed by the organization. Unfortunately, they did not describe the org chart we had been operating under. We had organized the list of functions in our framework along the life-cycle of the work, but when we started color coding which manager was responsible for which functions, the chart looked like a floor covered with confetti after a particularly epic New Year’s Eve party. And it was immediately apparent to everyone that the constant recurring arguments, bickering, and infighting we had accepted as inevitable actually could be mapped directly to these overlapping or unassigned responsibilities.

It was actually surprisingly easy to agree how the functions should be organized and assigned because everyone could easily visualize the change in the framework. It was easy to see that, while things were moving around, nothing was moving out. Indeed, it became obvious how many gaps we needed to fill, creating new opportunities. Nearly every manager lost some part of the responsibility they had previously thought fell to them, but nearly every manager also gained responsibilities. The resulting organization structure grouped functional responsibilities in a much more consistent, logical way. Managers were more focused and felt more ownership for “their part” of the project lifecycle.

This change, of course, also shifted around some of the front line resources, but by clearly communicating the new roles, the analysts, architects, developers, testers, and operations staff felt reassured and anchored, rather than adrift in a sea of incomprehensible change. They too felt a new sense of purpose and ownership that had been somewhat lacking before. I realize that this sounds like a fairy tale, but our employees went out of their way to give us glowing feedback on the changes we had made.

Clear definition of roles and responsibilities, and clarification of the relationship between roles is critical to the successful management of IT complexity. Oftentimes, the awkward and ambiguous roles we create are the biggest contributor to IT management complexity. After all, the roles are where the office politics are found. IT functionality is complicated enough without adding needless organizational confusion on top of it. Use your functional framework to tame IT complexity by clearly defining roles and responsibilities.