Above The Line IT

Background:

Architecture and Engineering are two terms often used to describe IT roles. In 2002, I was fortunate enough to work on a large Enterprise project using Spewak’s methodology. Prior to that project, I worked on many financial data related projects and intuitively was able to properly organize the data for maximum flexibility. My success with data was well enough known that other areas reached out to understand my approach. The Enterprise project in 2002 provided a methodology that aligned with what I had been doing intuitively, Since then, I’ve adapted the methodology for many different projects. It really didn’t matter the type of project (e.g. Configuration Management, Customer Enrollment, Eligibility) the methodology proved to be a pragmatic way to create an Architecture for the project. Projects always had two key components, business process and data required to support the business process.

From the forward to Spewak’s book: Enterprise Architecture Planning: Developing a Blueprint for Data, Applications And Technology :

“As I was reading this book for the first time, I was occasionally skeptical about a particular methodological point. However, in every instance, before I had read to the end of the chapter, I was convinced that the innovative and pragmatic approach to accomplish the purpose was sound.”  – John A. Zachman

My website, Above The Line It is about looking at IT solutions from a business perspective. The focus is to create a logical architecture along with clearly defining business data. Hopefully, over a series of posts I’ll be able to outline a methodology for a logical architecture that aligns with current applications of technology. The first step is to define the Architecture or more specifically a Logical Architecture for IT.

Architecture Definitions:

Architecture is described by Encyclopedia Britannica as:

“the art and technique of designing and building, as distinguished from the skills associated with construction. The practice of architecture is employed to fulfill both practical and expressive requirements, and thus it serves both utilitarian and aesthetic ends”

For the IT Architecture role, Gartner Architecture Glossary provides their definition of Architecture as:

1. In reference to computers, software or networks, the overall design of a computing system and the logical and physical interrelationships between its components. The architecture specifies the hardware, software, access methods and protocols used throughout the system.
2. A framework and set of guidelines to build new systems. IT architecture is a series of principles, guidelines or rules used by an enterprise to direct the process of acquiring, building, modifying and interfacing IT resources throughout the enterprise. These resources can include equipment, software, communications, development methodologies, modeling tools and organizational structures.

Britannica clearly separates Architecture from construction and implies Architecture is a combination of Art (expressive) and Science (utilitarian). Gartner mentions ‘logical’ a single time with the rest of the definition focusing on the orchestration of the technical aspects of the architecture (i.e. construction). A more robust Architecture definition requires aspects of both the logical aspects of Britannica’s definition and the technical aspects referenced by Gartner. The Logical Architecture does not require any specific technology in the initial steps of defining the architecture.

Technical considerations apply to a Logical Architecture similarly to how engineering guidelines apply to an Architecture designing a house. The Architect is aware of engineering guidelines to build. Those only serve to guide the architecture. The decision to use a laminated bean or a steel beam for support has little impact on the overall architecture of the house.

Logical Architecture Methodology:

The four pillars of creating a robust Architecture are Business Architecture, Data Architecture, Solution Architecture and Technical Architecture. The below briefly defines each pillar and how they relate to your final Solution Architecture used to construct a Business Application.

Logical Architecture starts with the business. The methodology consists of business process and data modeling. As you build out the business process model, it’s important to understand the data (data entities) that each business process uses. This will help organize business processes and data into a recommended Solution Architecture. Technical Architecture guidelines are used to construct the Business Application from the logical Solution Architecture.

Where to begin?

Start by putting the business first. On occasion you hear “IT Drives the Business”. I prefer to take the perspective of “IT Accelerates the Business”. The former puts IT first while implying newer technology improves business outcomes. The latter embraces the business to improve the current state and accelerate business critical decisions, improve response time to the market, or flexibility to deliver new services to the market.

Another aspect is you do not need to start by exhaustively deconstructing all the existing business applications currently used to run the business. This is expensive and time consuming process that is not repeatable. Rather take the approach of documenting business in terms of the business processes and key data concepts developing a deep understanding of the business. The entails documenting the logic and semantics of the business. Taking this approach defines solutions within the business context. At this point, you can inventory you current business applications and organize them by your IT Logical Architecture.

You can begin to lay out your architecture project by first taking into account that businesses have a natural “left to right” flow of processes and critical data components. Take the example of starting a new business. Most likely, it starts with an idea for a product or service (i.e. Product Development). The next step is to identify a target customer (i.e. Market Research) and hopefully you’ve been able to sell the product (i.e. Sales). This quickly defines business processes requiring further analysis. It’s also apparent how data relates to each process. This helps define foundational data for your business: Product, Customer, Sold Product which can be modeled.

Enterprise Architecture can conjure up visions of expensive, long running projects without achieving the promised benefit to the business. In some cases, Enterprise Architecture is described a big E and little e. As with anything, the larger the project the more risk for failure. Instead of Big E and little e, start thinking in terms of context. Logically looking at the sample business below shows three “contexts” to use for continued analysis. The contexts created are Product Development, Market Research and Sales. This allows project planning to define the effort in manageable pieces. Below is a sample notation used to visually depict the new business outlined. The shaded boxes are the high level business process, the lines indicate data flow and the open boxes depict data entities. The data entities depicted on the process model relate back to enterprise logical data model.

Immediately, three focus areas are identified along with the foundational data required to run the business. Market Research is taking the customer characteristics you plan to target and applying it to the universe of customers. The output (i.e. data) is Customer. Product development is defining the products planned for those customers. Sales would contact Customers identified from Market Research and hopefully sell the Products. The output again is data, Customer Product.

A close relationship between process and the data created by the process provides the context to develop your Solution Architecture. It’s at this point you can start to apply your technology best practices to create a target solution architecture. Understanding the process that creates each type of data begins to layout your data domains. For example, Market Research creates the Customer data. A best practice is to make this your company’s source of truth for Customer data.

Thinking ahead to a Market Research implementation, Market Research needs data services for all the actions required to maintain a Customer. This includes managing unique Customers along with data about Customers. The initial view is that all customers are created and maintained by Market Research. Reality is this is one source of Customer creation. Over time Customers can be identified via referrals, customer initiated or through sales contacts. Each one of these have the same data management needs to create, maintain and update Customer data that Market Research has. The scope of the solution should consider having Market Research develop a robust set of customer data services to share across the enterprise. These data services can then be presented via a variety of mechanisms for input.

Recommendation:

Before embarking on a effort to upgrade existing systems or purchase a vendor product, take the time to create a Logical Architecture of your business. A logical architecture is independent of any current implementations and can be used to evaluate how well current implementations meet business requirements.

A logical view creates a business context for evaluating current implementations and vendor solutions. Opportunities for data sharing and consolidation of applications is more obvious. Starting Above the Line IT, avoids the trap of re-engineering existing implementations with an expectation of getting better results for the business.

See my post discussing the difference between Architecture and Re-Engineering.

Modernization of business applications can take many forms. One approach is doing a deep dive into the current implementations to document the current state. Another approach is to create a technical architecture of the current implementations. In the first approach, the analysis attempts to identify the business requirements as currently implemented. Followed by a strategy to migrate to some future state (i.e. migrate from a monolith to a more modular solution). The second approach identifies current infrastructure and software used. This may result in a strategy to migrate to a new platform (i.e. from “on prem” to the “cloud”). Both approaches often end up re-engineering current implementations without gaining improvements for the business.

A third approach is to create a logical architecture of the business. This provides the opportunity for the business to re-think their current processes. Creating a logical architecture frees the business from any limitations embedded in current implementations. The logical architecture provides a vision for a future state without limitations. This avoids the trap of re-implementing existing, inefficient business processes. The diagram below depicts the relationships between logical and physical environments for current and future state architectures.

The diagram shows the current logical architecture state as it sits over the existing physical implementation. The line from 2 -> 3 shows taking the current logical business architecture state and moving to a future logical business architecture. The future state logical architecture is used to create the future state physical implementation. The overall success of any future state implementation is dependent on how closely the logical architecture aligns with the physical implementation (i.e. alignment of business requirement to implementation).

Unfortunately, it is not unusual for there to be gap between what the business wants logically and the physical implementation. This gap in the implementation results in additional steps or workarounds for the business. This is not uncommon when purchasing a vendor product to perform business functions. Vendor products are based on a logical architecture on how to best automate a process. The vendor product’s “Industry best process automation” is their value proposition.

The depiction below shows a misalignment of the logical architecture with the physical implementation. This happens when the business strategy is mis-aligned with the IT development strategy. The area in between 4A and 4B is filled by manual business processes to bridge the gap between two implementations. An example of a workaround is to require duplicate manual data entry to fill the gap.

Assuming there is not a current logical architecture of the business such as business process models, enterprise data models and the relationship of data to processes. It’s necessary to analyze the current implementation to establish the logical business perspective. This is followed by working with the business to modify the derived logical architecture into some future state implementation. This approach requires a lot of expensive, upfront analysis.

Logically, you can avoid the assessment of your current implementation and start directly with the business (box 3) to define the business logical architecture for the future state. This avoids the trap of re-implementing business processes that existed solely because “that is how the system works”. Your options are limitless giving you the freedom to re-think the most efficient way to run the business. This creates a context to organize and analyze current system implementations.

A Logical IT Architecture defines the foundation your business requires to function using process to data. From a strategy perspective, the architecture allows proper prioritization of efforts and highlights dependencies. For example, a business can not sell a product until you first have a product and find a customer. This logical approach provides a broad view of your business by removing all the detail complexities inherit when analyzing current implementations.

Below lists the characteristics comparing a Logical Architecture with a Re-Engineeirng effort:

Recommendation:

Start with the business, logically layout the business processes and data. Defining the business by creating a logical architecture uses a common language (logic) understood by both business and IT professionals. This becomes great medium for the exchange of ideas while defining a future state strategy. Dependencies and foundational elements of the business become clear. This logical architecture establishes context or domains for organizing current implementations.

Use can the logical architecture to organize the deep dive into existing implementations. Use the context provided by the logical architecture to organize your teams by their domain knowledge for any necessary analysis of current state. It’s likely a lot of time and effort (i.e. money) is saved taking this approach.

At this point, you’re ready to begin to layout the strategy you need to build your future state.

Worldwide master data management (MDM) software revenue will reach $1.9 billion in 2012, a 21 percent increase from 2011, according to Gartner, Inc.  The market is forecast to reach $3.2 billion by 2015.  Research by Dell ‘Oro group is predicting that the average storage requirements for fortune 1000 companies to grow from an average of 1.2 petabytes in 2011 to 9 petabytes in 2015.

Will the increased spending on MDM software be enough to manage the increase in data?   The good news is that it probably will.  One of the key aspects of MDM is to clearly define the data entities in clear unambiquous terms.  In addition, MDM also encourages a focus on having business processes to manage the data entities for accuracy.

This sounds good but you run the risk of investing a lot of money and not getting the return you expect unless clear objectives for the MDM project are established.   MDM was first introduced to address data quality issues and manage a single view of a customer or product. A successful MDM project clearly defines the business process, engages the appropriate people as data stewards and implements a tool set for managing the data (i.e.  People, process and technology).  In addition, a clear scope and definition of the business entities to be managed.   Without a clear definition of scope and purpose, the project will not deliver the desired business value.

Gaining agreement on scope and purpose is critical for success.   The purpose of the project includes the key performance indicators, KPI, used to  to measure the project success.   One simple KPI might be ‘percent reduction of returned mail.’  The candidate entity would be ADDRESS and MDM would be used to standardize addresses to facilitate identifying bad addresses, correcting addresses and managing  address changes.   Going through the effort of getting clean addresses is valuable to the extent this quality data can be leveraged across all systems.

Interestingly, a number of techniques used to load data warehouses can be managed by the MDM solution.   The first step when loading a data warehouse involves standardizing the data with ‘cross walk’ tables for codes (e.g. product code, risk codes).  A typical data warehouse goes through the process a cleaning the data to provide a single view of a company’s data.   The challenge is the timeliness of the data.

A data warehouse is going to lag behind and have data slightly older than what is in the online transactional systems.   The lag is caused in part because of the time it takes to transform data into the structure the data warehouse expects.  Employing an MDM can shorten the time it takes to make data available by managing a common set of IDs across systems.  This MDM ID can be used to load data of common entities into a single data store more easily.

Address, Customer, Vendor and Product are a few good candidate entities for an MDM project.  Address, as mentioned above, has a very tangible KPI, postage costs.   The value of managing Customer, Vendor and Product with an MDM project may be a little more difficult to measure.  Better management of these data elements would definitely help a company manage customer demand, understand costs and provide customer service.

A broadcast, Change Artists, caught my attention a number of years ago and I saved the Change Artist Transcript from the web.  Nestlé’s CEO Peter Brabeck and Deputy Executive VP Chris Johnson were interview.  I think the interview was around 2006.   The embarked on a worldwide project they call GLOBE with the objective of improving their data.  MDM requires a commitment of the right people, a solid process and systems that support the people and process aspects of the final solution.

The interview provides some great insight into how Nestlé improved the quality of their data.  Here are a couple of interesting comments from the project.

Well, the GLOBE Project, overall, is really not an IS/IT project. I think if it was I don’t think he would have chosen me to run it, because certainly that’s not my background or my expertise. It’s really a business initiative. – GLOBE stands for Global Business Excellence.

Steve Johnson

It’s clear that the business has set clear expectations for the project.

The first one was to implement harmonized best practices. So in other words, to take the best ways in doing business around the Nestlé world and share them. Very basic. The second one, which is not very sexy, but very important, is to standardize our data and our approach to data management; to treat data as a corporate asset. And the third one is to then support this and enforce it through standardized systems and technology. So it’s harmonized best practices, standardized data center, and systems.

Steve Johnson

According to the interview, these objectives were know across the entire company worldwide!   About 80 percent of the company was impacted.  The interview indicates the project spans 100,000 users across about 1200 locations of  factories, distribution centers, and sales offices.

They highlighted very tangible results from their GLOBE program.

Because quite honestly, we thought before the GLOBE program that we had 6 million customers, vendors, and materials. At least that’s what was in our systems. After going through the GLOBE exercise of cleansing, we realized that, well, about two-thirds of that was duplicate, obsolete, or just plain wrong.

Steve Johnson

Here is a great example of successfully improving data quality and company operations by implementing a project focused on data as an asset.  As evidenced by Nestlé, success is dependent on engaging the right people and having clear objectives.

Conclusion:

The original question was

Will the increased spending on MDM software be enough to manage the increase in data?

The original answer was ‘probably will’.  But seems to me, technology alone will not solve the problem.   Without engaging the business and having the right objectives, an MDM project is just another expensive IT endeavor.   MDM run from a business perspective to ensure delivery of business value is critical so the investment in the MDM projects will be worth IT.

In addition, the problem is not data volume but instead it is data velocity – making data available more quickly to the the business.  MDM speeds up the process of managing quality data and provides context for loading large volumes of data.  Once a quality MDM solution is in place, the increase in data volume can be handled with a scalable MDM solution.