Segment Architecture in a Commercial Setting

The notion of an Enterprise Architect in a Segment (aka “Segment Architect”) has been fairly well described in for the Federal Enterprise Architecture Framework.  (FSAM reference).  It is not always well understood, and there are a small number of blog posts that disparage the concept.  That said, in a federal context, the politics of enterprise architecture doesn’t seem to get played out across the blogosphere. 

I am getting moderate traction at implementing the notion of segment architecture in a commercial setting, and I’d like to share my experiences with the community.  This post is one of what will likely become a series of posts on the trials and tribulations of implementing commercial segment architecture.

Preface: FSAM without the bureaucracy

First, a caveat and caution to those folks who are intimately familiar with the implementation of the Federal Government version: while I took a great deal of inspiration from FSAM, I cannot pretend that I have made any real effort to implement the FSAM in my organization.  As an outsider to Federal IT governance, I am looking through a very narrow lens.  The OMB is the overseer of overseers.  They rely on reports submitted by the agencies themselves.  Each agency is a large organization with billions of dollars of funding. In order to support the multiple tiers of oversight demanded by Congress, huge amounts of information must be put into standardized reports and fed upstream for oversight.  This emphasis on standardization and documentation is simply overkill in a commercial setting, where governance is a matter of judgment, and not a campaign pledge or a debate on CSPAN. 

I appreciate the difficulty of the OMB’s job.  I’m glad I don’t have to do it.  In that vein, I started my implementation of segment architecture by tossing out the extraordinary reliance on reports.  I stuck to the goals and concepts of segment architecture.  And that's where I’d like to start in this post: what problem does segment architecture solve?

The ivory tower problem

The first step in understanding a problem from an architectural standpoint is to explain the problem as a set of interacting responsibilities.  For folks of the BPM bent, this can mean looking at a series of high level business processes.  For folks of a more architectural nature, this is often thought of as a set of interacting capabilities, each of which produces, consumes, or manages information as part of a larger system dedicated to a goal.  These architectural models are extremely useful, because they help to create a mechanism for understanding the problem space and for creating clear solutions.

However, reference models and taxonomies are not solutions.  No one can implement a reference model.  These “thinking tools” are inputs for specially trained individuals, and cannot be used by business people.   Reference models are architecture, but they are architecture for architects.  They are the patterns that architects use, not the blueprints that builders use.

On the other side, there are problem solvers.  Traditionally, in both business and government, an empowered individual will decide that “my organization will go after this goal” and they will direct their team to get to work.  The team may have to modify their existing processes or change their existing systems, and the goal is quickly broken down into a gap analysis, a proposed solution, and an implementation program.  The program will trigger and manage a series of projects and the results will be measured and reported. 

These activities are well understood and problem solvers have been promoted into management on the basis of doing these activities well.  As a result, there is great understanding for them, and support of them.  This culture does not care about reference models, taxonomies, or assessments.  This culture is well populated, and is seen as either the solution or the problem (depending on whether they are successful or not).  This culture of problem solving often outnumbers the architects (100 to 1) and they are slow to change. 

To the problem solvers, enterprise architects live in an ivory tower. They create models that are correct, but useless.  They do work that is visible, yet not necessary.  They spend time and money without solving any real problems.  To the problem solvers, a reference model is pretty useless.  A reference model plus $5 will get you a cup of coffee. 

Building bridges from both directions

In order for the problem solvers to gain any value at all from the reference models and taxonomies, those artifacts need to be correct and relevant.  Without specific information, they can be pretty, but not pretty useful.  From the solution side, enterprise architects need to gain understanding, relevance, and a tie to the work that actually must be done, the dates it must be delivered in, and the costs that play out across the infrastructure.

For the enterprise architects to have an impact on the problem solvers, their models must also be understood, and there has to be a set of key individuals who use those reference models to get the problem solving moving forward.  There has to be an understanding of how to use the information collected, and how to solve specific enterprise problems.  The problems that an EA is trying to solve are different problems than the ones the business is focused on.  The EA problems are around total cost of ownership, not solution development.  They are around consistency, simplicity, and reliability.  They are not normally focused on specific features, specific constraints, or specific interfaces.

A bridge must be built.  The realization that led to segment architecture is that this bridge cannot be done with training or artifacts or databases… the bridge is constructed of people.  Those people are Segment Architects.

Enterprise, Segment, and Solution Architects

In the problem solving space, you need solution architects.  These are the folks who will build the actual solutions that the business needs from the parts available (existing systems, databases, processes, hosting providers, authorization systems, etc.).  In the enterprise space, you need the enterprise architects.  These are the folks who evolve the future state for the enterprise’s processes, information, roles, and tools.  In the middle, you need the segment architects.  These are the folks who work with the business during the goals, gaps, and solution stage to insure that they enterprise needs and solution components come together. 

The segment architect is responsible for the following:

• Developing a deep relationship with the business and developing a deep understanding of the problems that need to be solved.
• Understanding the reference models and providing the needed information to build, evolve, improve, and implement them in the segments.
• Assessing the state of the processes, information, roles, and systems that are involved in a particular business area to inform the solution efforts
• Developing the initial “conceptual solutions” needed in order for the programs and projects to get under way, and for the solution architects to have a reasonable and achievable scope to operate within.

 

The distinct role of Segment Architect

For a while, I’ve had a challenge that is not simple to explain: how is a Segment Architect different from the other roles.  Not simple.  Here’s my attempt for tonight.

First off, let me say this: a Segment Architect is an Enterprise Architect.  He or She is assigned to work within a segment, but could be reasonably assigned to another segment (and in fact, should be periodically reassigned in order to retain their independence).  The segment architect is accountable for all of the responsibilities of an enterprise architect.  He or she must “own” enterprise requirements and insure that they are implemented in line-of-business solutions to the best of his or her ability.  As an EA, they care about where information is created, where it is mastered, and where it is manipulated.  They care about which business units perform specific business processes at a high level, and which governance mechanisms will be used to measure results. 

That said, in the early planning stages, the Segment Architect fills in the (not-yet-funded) role of a solution architect.  He or she will consider all of the requirements, well before they are reasonably understood, using the reference models and taxonomies as analysis tools.  They will develop a conceptual solution that allows the organization to understand what teams will be involved, what systems will be targeted, and what information should be mastered.  Without the segment architect assigned, the business units will perform this architectural activity without any architects in the room, and the result is quite dangerous.  That said, the solution concept developed by the segment architect is a pencil sketch compared to the actual solution that will go live.  It is directionally correct, but the real solution may take on a very different character.

The segment architect does not get the privilege or the honor of actually delivering the solution.  That honor, and that responsibility, falls to the solution architect who will be held accountable for meeting enterprise requirements as well as solving specific business problems.  The solution architect is assigned to the actual project, and has to deliver on it.  The EA does not.

Tell me what you think

I hope that this article provides some of the basics of segment architecture for the EA community, and opens up a channel of dialog about this important and emerging role within the Enterprise Architecture profession.  I am open to questions and concerns, which I may answer in subsequent blog posts.  Please feel free to share your ideas.

One bit of credit that I’d like to give.  Finding an image of a chasm that business people can cross is not easy.  The images if a chasm that I used in this blog post originated from an April 2004 article on the IBM web site called “Bridging the Chasm between Strategy and Execution” by Sydney Fuchs.  The article is quite good and I recommend it, but the context is not quite the same as I used in the image here.  I did not ask for permission before absconding the image, modifying it, and repurposing it.  I hope that Mr. Fuchs will forgive the intrusion.

Comments

• Anonymous
  April 25, 2011
  Nick, this is an interesting read since I have been working around the 'cloud' known as a segment architect for the last 4 years at Blackboard. With a change of management (VP-Development) at the end of 2010, there was a purge of everything above the development teams (all future R&A - Research and Architect) disappeared or was merge into development teams. I suspect Desire2Learn will infringe on Blackboard more and more over the next few years. There's a lot of human-ware involved and the key may boil down to whether or not the VP or Director responsible is 'technically knowledgeable' or a pure 'manager'. A pure manager will like hear gripes from the lower echelons about EA being a waste of time ("we can do it just as well while building the solution"). One interesting difference between government and commercial may be the length of residency in a position (or the position stack). In government service, this tend to be very long. With commercial, very short.  With one, you can establish the appropriate culture, with the other --- any culture may be swept away with the next mid or upper level management change where a career-politician manager is dropped in.

• Anonymous
  April 26, 2011
  The comment has been removed