#segment architecture

Enterprise architecture develops the architecture for the enterprise, right? You’d think that’s a no-brainer. Except what happens when the enterprise is so large and complex that it defies the efforts to architect it?

Federal Computer Week (FCW), 24 March 2008 reports that Dennis Wisnosky, the chief architect and chief technical officer for DoD’s Business Mission Areas states that “the Department [of Defense (DoD)] is too large an organization to attempt to encompass all of its activities in a single enterprise architecture.”

Similarly, FCW, 26 November 2007, reported that “the size of the Navy Department and the diversity of its missions make it impossible to describe the service in a single integrated architecture.”

Dennis Wisnosky goes on to say that “DoD must achieve business transformation by breaking off manageable components of an enterprise architecture rather than trying to cover everything at once…[this is how we will achieve] the goal of an enterprise architecture [which] is to guide future acquisition and implementation.”

Richard Burk, former chief architect of the Federal EA (FEA) at OMB states: “there is no practical way to create a useful architecture for a large organization. You can get an overall picture of an agency using an [enterprise architecture] of everything the agency does, but when you get down to making it operational, at that point you really need to break it down into segments, into the lines of business.”

The Navy is using the concept of segment architecture, but is calling it “architecture federation.”

Michael Jacob, the Navy’s chief technology officer, “compared the architecture effort to the development of a city plan, in which multiple buildings are built separately, but to the same set of standards and inspection criteria.”

Mr. Jacob continues that “our effort will allow common core architecture elements [technical standards, mission areas, business processes, and data taxonomies] to be identified so that architecture efforts can be aligned to those same standards.”

I believe that every level of an organization, including the highest level, can have a architecture, no matter what the size, and that we should tailor that architecture to the scope of the organization involved. So for an organization the mega-size of DoD, you would have very little detail in at the highest level, EA (like the FEA Practice Guidance demonstrates), but that the detail would build as you decompose to subsequent layers.

For any organization, no matter its size, every level of the architecture is important.

Within the enterprise architecture itself we need multiple views of detail. For example, from an executive view, we want and need to be able to roll up organizational information into summary “profiles” that executives can quickly digest and use to hit core decision points. At the same, time, from a mid-level manager or analyst view, we want and need to be able to drill down on information—to decompose it into models and inventory views--so that we can analyze it and get the details we need to make a rational decision.

Similarly, within the overall architecture, we need the various views of enterprise, segment, and solutions architecture. The enterprise view is looking at strategic outcomes for the overall enterprise; the segment view decomposes this into actionable architectures for the lines of business; and the solutions architecture “brings it all home” and operationalizes the architectures into actual solutions.

Architecture and Governance Magazine, Volume 4, Issue 1, has an article called “The Secrets of IT Success: Transforming Companies” that identifies three critical architectural elements necessary for successful IT project execution, or as I see it, project initiation.

These critical IT project elements are as follows:

Community Analysis—“It must understand the needs of the customers, the supply chain, and the transactions necessary for the day-to-day running of the business…generate understanding on both the business and IT sides of the equation, to capture organizational goals comprehensively, and to enable effective training and buy-in, IT analysts and engineers must identify with and embrace the community to be transformed.”

Operations Analysis—“A deep understanding of the operational activities, capabilities, and business processes…Here work activities are identified, captured, and catalogued so that information flows, technologies, roles, and other processes and elements can be accurately mapped. The analytical results from this phase give a clear perspective to move from the business’s needs to the requirements of the new technology that will need to be implemented.

Technology Analysis—“technical needs are defined and blueprinted, and their intersections with business rules are specified…A multidimensional analytical view encompassing user workflow, technologies, data, security, business rules, and interfaces can greatly enhance the pure IT view of transformation.”

To me this translates in simple terms to the following:

Business needs

Functional and technical requirements

Technology solutions

While these IT project elements factor into the development of the enterprise architecture, they are more the domain of segment and solutions architecture that work toward business and operational outcomes, rather than strategic-level outcomes.

The article also calls for the use of visual tools to aid in IT project analysis:

“In all three phases, a key ingredient is supplying a visual tool as part of the universal language that will be used throughout the project to facilitate clear communications between members of the community affected by it. Consistent and unambiguous visual expressions of the operational need and intent immeasurably enhance the likelihood of a successful IT implementation.”

Modeling business processes, information flows, and the systems that serve up that information is core to developing enterprise architecture

DM Review Magazine, February 2008 reports that Business Process Management (BPM) changes the game for business performance through process innovation, creating a process-managed enterprise that is able to respond to changing market, customer, and regulatory demands faster than its competitors.”

How does BPM enable enterprise efficiency?

“It acts as the glue that ties together and optimizes existing attempts at employee collaboration, workflow, and integration. It drives efforts in quality improvement, cost reductions, efficiencies, and bottom-line revenue growth.”

BPM drives “the ability to design, manage, and optimize critical business processes.”

Essentially the decomposition of functions into processes, tasks, and activities along with linkages to the information required to perform those and the systems that provide the information enable the enterprise architect to identify gaps, redundancies, inefficiencies, and opportunities for business process improvement, reengineering, and the introduction of new technologies.

Business, data, and systems models are an important tool for architects to integrate and streamline operations.

How effective is BPM?

The Aberdeen Group reports “more than 50% of companies surveyed were expected to turn to BPM in 2007 to get the process right at the line-of-business level without having to throw out their expensive enterprise resource planning (ERP) or custom back-end applications investments.”

Similarly, Gartner reports that “organizations deploying BPM initiatives have seen more than 90 percent success rates on those projects.”

What are some critical success factors in BPM?

Usability—“intuitive and flexible user interfaces.”

Process analysis—“knowledge management, analytics, reporting, and integration functionality.”

Collaborative—“portals, attached discussion threads, document management capabilities, and configurable task views.”

Self-optimization—“ability to ‘self-optimize’ the process.”

Focus on high-value areas first—“initial BPM project should include areas of medium-to-high business value combined with low process complexity…choose processes or business areas that have high visibility.”

There is a terrific white paper from the National Institute of Health (NIH) called Enterprise Architecture: Engaging and Empowering People while Creating Opportunity for Change.

NIH conducted a qualitative research study involving 15 users to understand how user behave and work in order to identify opportunities to foster adoption of EA.

First, NIH identified a clear mandate to not only develop and maintain EA, but for its end use:

“Enterprise Architecture (EA) is a critical part of IT strategy in any organization. However, just defining enterprise architecture doesn’t bring its true value of efficiency to the organization nor support for the organization’s strategic objectives. In the EA Assessment Framework 2.0 published by the Office of Management and Budget (OMB) in December 2005, three capability areas, Completion, Use, and Results are defined as primary objectives of every government agency’s EA program. It is clear that EA is not just an assignment for CIOs to document architecture standards for the agency—for the future value to be realized, it must be used to achieve results.”

Second, NIH identified 3 user segments that are each looking toward the architecture for satisfying different needs. (While the study views all three segments as belonging to EA, I believe that only the first is EA, while the other two are segment and solution architecture.)

Trend Finders—want to know “where we are going?” They are interested in understanding the current and future business and IT landscape. (I believe this equates to enterprise architecture and its focus on developing the as-is, to-be, and transition plan.)

Fit Seekers—want to know “Does it fit my projects?” They want to find a solution for the project. (I believe this equates to segment architecture and its focus on developing solutions at the line of business (LOB) level.)

Fixer-Doers—want to know “How to make it work?” They want to build, maintain, or support a project. (I believe this equates to solutions architecture and its focus on developing technical project solutions for the end-user.)

While the study posits that user segments are not mutually exclusive and that users can actually evolve from one segment to another (and of course this is possible in some cases), I believe that generally speaking the segments do represent unique architecture perspectives in the organizations (enterprise, segment, and solutions architectures as defined in the Federal Enterprise Architecture Practice Guidance, December 2006).

In summary, architecture users are looking to understand the big picture (the EA and IT strategic plan), justify decisions (develop segment architectures that are ‘justified’ by aligning to and complying with the overall EA), and make it work (develop solutions architecture using technical details from the enterprise and segment architectures).

User-centric EA can satisfy the various segment needs by following the opportunities identified in the study to improve EA use. These are as follows (modified to more accurately represent what I believe is their correct application to users.)

For trend seekers/EA:

Show the big picture—high-level, non-technical information about the EA (this equates to EA profiles) and the direction of overall business and IT initiatives (this is the business, EA, and IT strategic plans)

Provide access to the source—ways to find more information and points of contact

For fit-seekers/segment solutions:

Lead to the right information—clear guidance through understandable nomenclature and information structure

Provide proof—through IT investment Review Board and EA reviews that include findings and recommendations.

For fixer-doers/solutions architecture:

Give specifics for immediate help—through more detailed EA models and inventories as well as SDLC job aids.

For all:

Share and enhance—capture performance metrics on EA program and products, especially use of EA information and governance services.

For many years, there was confusion in the architecture community between EA and solutions architecture. For example, I remember one of the agencies that I worked at putting together a request for proposal for contractors to develop an EA for some new systems. But it wasn’t EA that they were actually looking for; they really wanted a solutions architecture to automate some particular processes (but at the time they didn’t know the correct terminology or really understand the distinction).

However, the distinction is important and the Federal EA made major strides in this area in December 2006, when they released the FEA Practice Guidance that laid out the differences (and hierarchy) between Enterprise, Segment, and Solution Architecture.

(At the highest level,) Enterprise Architecture is scoped on the agency, at a low level of detail, with impact focused on strategic outcomes, and the audience is all agency stakeholders.

Segment Architecture is scoped on individual lines of business (LOB), at a medium level of detail, with impact focused on business outcomes, and the audience is the line of business.

(At the lowest level,) Solutions Architecture is scoped on specific functions and processes, at a high level of detail, with impact focused on operational outcomes, and the audience is users/developers.

Why is this important?

From a user-centric EA perspective, all stakeholders benefit from a clear delineation of responsibilities: An overarching plan and governance is provided from the Chief Enterprise Architect (the strategic layer); a roadmap for the lines of business is served up from the program managers (the logical layer); and project solutions are developed by the technical staff (the physical layer).

Al three layers of the architectures work synergistically together for the end-user, by the lower levels aligning to and complying with those above, so that specific solutions fit into the line of business roadmap for enhanced business outcomes, and the LOB roadmaps, in turn, are aligned with the overall EA target architecture and transition plan for the organization.

ComputerWorld, 22 June 2009 has an opinion piece, called “The Benefits of Working Together,” about developing an “Industry Architecture (IA)”—in this particular case for the hotel industry.

It takes the concept of a company or organizational architecture and applies it across an entire industry.

“In difficult economic times, every company seeks cost reductions and process improvements. But now an entire industry has banded together to help its constituents maximize their IT-based assets.”

I can see how from a private sector approach, IA is a way for companies to work together and benefit their overall industry through:

Improved IT products—“a clear architectural roadmap allows suppliers to focus efforts on the capabilities most important to customers.”

Lower IT product costs—standardized products from suppliers are generally less costly to produce than customized one (but they are also less differentiated and may be less exciting and inviting to customers). The IA also facilitates component reuse, standardized interfaces, and so forth.

Lower training costs—IA could reduce training costs, since there are standard processes and products spanning the entire industry meaning that employees can move more seamlessly between companies and not have to learn a whole new way of doing things.

Improved agility—industry standards allow for faster deployments and configurations of IT.

Increased buyer confidence—industry architectures could provide for a “product certification program”, so buyers can have confidence that IT products meet guidelines and are interoperable with other IA certified products.

Improved security—IA can incorporate IT security standards, resulting in companies being more secure than if they had “conflicting security approaches.”

From a public sector perspective, the Federal Enterprise Architecture (FEA) is similar to Industry Architecture in the private sector. Ideally, the FEA looks across all the federal departments (like an IA looks across the various companies in an industry) and creates a roadmap, standards, certification programs, interopability, component reuse, umbrella security, and more resulting in lower IT costs, more agility, and improved service to the citizen.

In terms of naming conventions, we can come up with all types of architectures from company architectures to industry architectures, from solution architectures (for meeting specific requirements) to segment architectures (for specific lines of business). We can develop horizontal architectures (across entities in the same stage of production or service provision) or vertical architectures (in entities that span different stages of production or service provision). We can create national architectures (like it looks like we may end up doing the financial services sector now) or perhaps even global architectures (such as through environmental, economic, or military agreements and treaties).

Whatever we call the various levels of architecture, they are all enterprise architectures (just with the “enterprise” representing different types or levels of entities). In other words, an enterprise can be a company or industry, an agency or a department in the federal government. Some enterprise architectures are bigger than others. Some are more complex. But what all these enterprise architectures have in common is that they seek to provide improved IT planning and governance resulting in cost savings, cost avoidance, and performance improvement for the enterprise in question.

In enterprise architecture, we routinely plan for new information technologies and not enterprise anything. In fact, what we now interpret as the federal mandate for “enterprise architecture”, the Clinger-Cohen Act of 1996 really mandated not enterprise, but “IT architecture”. Here, architects didn’t typically develop enterprise (or common) solutions, but rather stovepipe solutions per customer demand. I would call this Enterprise Architecture 1.0. As enterprise architecture evolved, we saw it mature in its implementation and expand beyond pure technology into the realm of business process reengineering and improvement. This manifested itself in the Federal Segment Architecture Framework of 2008, where we now looked to solve business, not IT, problems for logical business segments of the organizations. This is Enterprise Architecture 2.0.

However, even at this level of maturity, it continued to be somewhat rare to find enterprise architecture that looked at how we are transforming people, organizations, culture, and society itself. This is now beginning to be demonstrated in the architecture using social media and the larger implications of widespread information sharing, collaboration, and broader citizen participation. I would propose that this larger view of, and larger participation in, enterprise architecture is the next evolution and represents Enterprise Architecture 3.0.

Interestingly enough, I read in ComputerWorld, 18 May 2009, an article that took just such a enterprise architecture 3.0 view, called “Are Computers Transforming Humanity” by Mary K. Pratt.

Note, it’s not that these types of articles have not appeared in the past, but rather that they were not as frequent and this thinking not as endemic to the everyday IT planning discussion as it is becoming today.

The article states: “We’ve always had the introduction of new technologies that transform and move society in new ways. It changes our interactions, our sense f the world and each other…what individual and cultural transformations do, new computer technologies portend.”

Here are some of the EA 3.0 trends I gleaned from the article that are starting to manifest in people, organizations and society:

Convenience weighing on privacy—We can plan for new technologies (for example, mobility solutions that yield “quick answers and fast transactions”) to continue that advance of convenience and challenging traditional privacy concerns. As the article states: “what we let hang out there has changed.”

Reaching across all boundaries—new technologies will continue the miraculous feat of breaking down organizational and societal stovepipes. “One of the things that is different today isn’t that we can just act collectively very quickly, but we act across heterogeneous groups.” Plan for IT to reach across boundaries globally (and even inter-galatically, in the not too distant future).

Digital narcissism—technologies are enabling people’s self-indulgent practices where they often use social media tools to “reinforce and further rationalize overblown esteem for their mundane opinions, tastes and lifestyle choices.” We web 2.0 tools like blogs and twitters and social media everyone can have their own soapbox to evangelize from.

Multi-tasking galore—with the constant barrage of new technologies and communications from them, we are forced to multi-task like never before. “Studies have found that the amount of attention many of us can devote to a single specific task is about three minutes—15 minutes at most.”

Learning by doing—“Why should we memorize facts and figures when search engines, databases, and increasingly powerful handheld computing devices make them instantly available?” What we used to have to memorize, we can now just do the look-up for.

The implications of moving and maturing to Enterprise Architecture 3.0 are exciting and will have us thinking long and hard about the implications of what we do in and with information technology well beyond anything we have done before with IT for individuals, units, or line of businesses.