Enterprise Archi-Treasure

by Jeff Tash, ITscout

Enterprise Architecture, according to TOGAF (The Open Group Architecture Framework), consists of four distinct types of architecture subsets: 1) Business Architecture; 2) Data Architecture; 3) Application Architecture; and 4) Technology Architecture. Let’s begin by briefly examining each of these.

Business Architecture revolves around business processes. Much of today’s work in this area reflects an evolution of ideas originally introduced during the 1980s and 1990s by two earlier strategic initiatives: BPR (Business Process Reengineering) and TQM (Total Quality Management). Those were heady days back then for prestigious and expensive management consulting firms -- back when money for Harvard MBA-style consultants was flowing quite freely -- long before the dot coms and dot bombs.

More recently, BPEL (Business Process Execution Language), an XML vocabulary, has achieved widespread recognition as the language of choice for business process modeling. BPEL provides a way of communicating process descriptions between different tools, or of passing a company’s process descriptions along to its business partners. Unfortunately, the current BPEL standard is still very much a work in progress. The people who defined BPEL opted to omit from the specification certain issues where major disagreements existed among committee members, particularly how to support non-automated manual activities. So, proprietary extensions to the language often get introduced making it nearly impossible to exchange BPEL across different vendor implementations.

I recommend you begin the modeling of Business Architecture by concentrating first on business events. You’ll find these represent the most reusable facet of your computing environment. Next, try to assert control over the specification of business rules because these reflect the most volatile aspect of your computing environment.

Data Architecture has matured significantly from its origins back when people simply drew paper-and-pencil ER (entity and relationship) diagrams using rectangular boxes and lines. Nowadays, architects have been provided with modeling and documentation techniques that extend to incorporate object-oriented metadata concepts such as composites (whole-to-part) and inheritance (generic-to-specific), as well as OLAP aggregates (On-Line Analytical Processing) that support drill-down, roll-up, and slice-and-dice functionality. The beauty of Data Architecture comes from its remarkably stable nature, especially by comparison to the highly dynamic Business Architecture with its forever-changing, and often complicated and convoluted, business processes.

Application Architecture combines portions of processes together with pieces of data into separate independent software programs that can execute on top of a safe and secure computing infrastructure.

Application Architecture is responsible for the specification of the set of API’s (Application Programming Interfaces) that enable application partitioning across distributed computing platforms. It’s also responsible for the API’s that support application integration across multiple products.

Service-Oriented Architecture (SOA) -- the next major wave of Application Architecture -- is going to be huge. We’re talking Windows-huge or World Wide Web-huge. SOA is the perfect platform for tomorrow’s pervasive, wireless, massively distributed computing future. SOA will be the industry standard Internet middleware for at least the first couple of decades of the 21st century. SOA will handle all partitioning and integration tasks as well as provide full support for directory and security services. My advice is that now might be a good time to jump onto the SOA bandwagon. Think of it like a surfer. There’s this big beautiful wave rolling in. If you start paddling right now you ought to be able to catch it perfectly for an exhilarating ride.

Technology Architecture describes the safe and secure computing infrastructure where applications execute. The first thing this description needs to indicate is which products have been selected as internal corporate standards (as well as which products have been evaluated and then rejected). Often, you’ll want to identify both ‘as is’ as well as ‘to be’ standards.

In order to be of value, these lists of standards must be presented and organized according to a set of hierarchical category trees that collectively define a taxonomy. Otherwise, it’s too complex and confusing to understand what you own. Basically, you want a way to group and join together similar products with equivalent or overlapping functionality.

A beneficial byproduct of standardization is consolidation which almost always results in a significant decrease in technology portfolio costs. That’s Archi‑Treasure -- helping IT look great in the eyes of CFOs and CEOs.
 

Why Standardize Your Enterprise IT Infrastructure
It doesn’t matter what performance metric you choose to measure, you’ll find that standardizing your IT infrastructure will improve your enterprise’s efficiency by lowering costs, shortening cycle times, and reducing staffing. Simultaneously, standardization, coupled with consolidation, will increase IT effectiveness.

Standards really do enable an IT organization to do more with less. If you want a responsive, agile IT organization, then adopt a simplified, streamlined, less complex, standardized computing environment.

Standards adherence helps drive growth. Scaling, a major challenge for IT, can be accomplished by standardizing using low-cost products that can be bought in small bite-sized chunks rather than requiring large capital investments ahead of the business need curve.

Standardization goes hand-in-glove with integration. The adoption of standards makes it much easier to develop holistic manageware solutions that combine installation automation, remote monitoring, and change management. This enables the creation of simplified operations, improved utilization, and optimized cost-effective scaling.

Standardization improves security by helping to speed identification and plugging of security holes. The alternative, complexity, often hides problems under the covers.
 

Oftentimes the toughest challenge when beginning a standardization initiative is finding someone who can muster the courage to commit to conducting a technology audit. The goal of the audit is to identify previously purchased products. That is rarely easy. Architects frequently complain how nobody wants to admit what software they own. My guess is that most people would prefer not to fess up. An unimaginable number of products purchased in the past are today shelfware. Huge investments sit idle. Many other products get rarely used. This invisible and silent technology portfolio is like the proverbial elephant standing in the middle of the room. No one wants to admit it’s there. The sad truth is that many technology portfolios are an embarrassment of redundancy and waste.

Many enterprises consist of information silos. This frequently causes a fundamental disconnect between business needs and IT capabilities. Inadequate communications results in poor buy/build/drop decisions. Worse still, the lack of tools to support IT standards causes the cycle to repeat over and over again. On the other hand, organizations that can successfully bridge the communication gap across different silos benefit by sharing best practices, improving knowledge sharing, and increasing purchasing power when negotiating with vendors.

  figure 1

I have found the best way to describe IT standards is to represent Technology Architecture as three layers (see Figure 1). At the base, or bottom layer, sits a foundation that corresponds to IT infrastructure. Although infrastructure is enormously expensive and complex, by itself, it doesn’t really do that much of anything. Value is achieved only after applications get layered on top of the infrastructure. The middle layer, representing applications, needs to address two fundamentally different sets of products, depending on whether you build or buy software solutions. Regardless of whether applications are developed or purchased, either way, data is captured that contains a wealth of information. The only question is the enterprise’s willingness to leverage that top layer data in order to generate business intelligence.
 

Standards Manifesto
Standards are good. It’s hard to imagine a scenario where establishing and communicating IT standards won’t, at the very least, result in significant, measurable hard dollar savings. Therefore, I encourage you to establish standards.

How do you begin? Focus on communicating information about products, vendors and category trees. Identify and list past technology investments, and then classify and categorize each so that it fits within your Technology Architecture taxonomy. Not everything in the Technology Architecture has to be captured all at once up front. You’ll find that the knowledge base will grow organically over time.

Want to be a hero? Then, roll up your sleeves. Perform a technology audit. Categorize past technology portfolio investments. Establish and communicate IT standards. Then step back and enjoy as the Enterprise Archi-Treasure savings come pouring in.