Getting What You Need from Your Enterprise Architect

This article captures a session at the recent conference of the Data Governance SIG of the Americas SAP User Group (ASUG) by George Bryce, Corporate Data Architect at Procter & Gamble.

George started off with a good introduction to what governance organizations require in order to be successful:

  • understanding the big picture and how the pieces fit together,
  • designing the right processes with auditing, rules and controls,
  • creating measurements and proof points,
  • implementing the right tools, and
  • having the right people in place and the right organizational support.

Whether people are starting from a blank sheet of paper, or are trying to build on something they’ve already got, they need to get to a point where they’ve got something people can use, with the right systems and tools for the enterprise.

At Procter & Gamble, after being on SAP for 25 years, they realized they were maintaining integrated master data across their landscape and any field that was “off” was going to break something downstream.

Enterprise architecture supported data governance through:

  • Impact analysis – when a new business requirement comes up, the impact needs to be investigated with concrete metrics to understand what applications and business processes need to be changed.
  • Documentation that data is being used according to standards, and recording where exceptions and violations are taking place
  • Metrics to the level of governance in place and a roadmap for change

It’s very common, for example, to have two different groups using the same field in different ways. So a “customer channel” field might start out being used for financial analysis in North America, but it can change over time to support pricing in Europe. So it’s important to understand those dependencies when you go to make changes.

It’s important to put frameworks in place as part of the roadmap process for the next few years, and to know from where you’re starting.

George’s definition of Enterprise Architecture was great: “City Planning for IT”. Where does the business want to go? What capabilities are they going to need in terms of:

  • Business processes are the processes the business uses to meet its goals and to transform the business.
  • Applications are what users actually “touch” to perform the business processes.
  • Information is how the enterprise’s data is organized, processed and used in applications.
  • Technology is the underlying building blocks for all of the above.

Architectural frameworks help by providing a “big picture”, as well as standards for organizing and presenting business and technical architecture components.

Architecture governance is the collected principles, decision rights, rules and methods to drive architecture development and alignment in the organization.

Architecture value is defining, measuring and communicating the value and impact of architecture to the business.

Architecture planning defines the vision and roadmap for IT domains by anticipating business needs and trends, and developing the necessary architecture components.

Strategic planning uses architecture principles to align business needs with IT capabilities, define portfolio strategy and allocate resources.

Communication and stakeholder management is critical as well.

A framework means you don’t have to start from scratch. SCOR (Supply Chain Operations Reference) goes down to Level 3. The American Productivity and Quality Center (APQC) takes it down one level further. And a newer group (Value Chain Group, VCG) is even more detailed in terms of low-level process design.

This gives you a communication structure internally between organizations and externally to validate best-in-class processes.

An enterprise architect can help by providing an Enterprise Conceptual Data Model, which enables an accountability structure. For example, raw material, product, order – all have high-level owners, and may also have sub-owners – for example, basic data, sales data, plant data, etc.

If you don’t document – at least at a medium level – seeing the relationships between the data gets impossible. If you’re just managing a portion of a domain, that’s just where you’re starting. You know that you’ll have supply chain, HR, Finance, etc. dropped on you at some point.

Figure out what are those critical business fields, and put together the documentation in the form of a conceptual data model and metadata. Even in a system such as SAP that might have hundreds or thousands of tables, there’s usually less than a dozen tables that are really critical.

The data model also helps you see the big picture. You can grow your conceptual data models into a metadata repository, perhaps by working at the “data group” level. The high level domain (or subject area) can be broken down into 7-10 data groups or “data chunks”, which can be broken down into the critical fields in each data group.

Knowing what the 25-30 fields are that are really critical to your business will pay many different types of benefits. So data modeling (not necessarily at the physical level) will be very helpful. And managing it in Excel just isn’t going to work.

At P&G, the Excel model was 26,000 lines long, just for the Material domain (and they have 38 different domains). But putting that into a conceptual data model makes it so much easier for executives and business partners to understand. And this drives more accountability, because you can more easily define the scope of what people own.

And the world of big data is here. It won’t be long before people are trying to use big data to make decisions, and maybe make them incorrectly because they don’t understand the underlying models.

It’s important to establish a culture and process where projects have architecture and governance reviews at each stage gate, to:

  • Identify what data is needed
  • What business processes will produce the data
  • What business processes will consume the data
  • Is data being used according to standards – if not, change the project’s use of the data to conform, get an exception, modify the standard, or stop the project temporarily

This will provide a jumpstart for governance projects to understand how data is being used according to standards.

Some of the tools that can be used to manage the models and documentation include:

  • PowerDesigner from SAP (formerly Sybase)
  • ARIS
  • MEGA
  • Erwin
  • etc.

Tools not sufficient for enterprise architecture documentation:

  • Excel
  • PowerPoint

This allows you to drill down, much like with Google Earth, to see the world of data in ways you never thought you could do before.

Some key learnings from Procter & Gamble:

  • Your enterprise architects can play a big part in lending their brain power to your program and ensuring the success of your data governance projects
  • If you don’t know who they are, find them and see how you can collaborate with them
  • Enterprise architects can help you convert your ideas into something people can use, with the right systems and tools for use in your enterprise.

A special note: George Bryce contributed to the book “Enterprise Information Management with SAP” (available from SAP Press), which helps people understand products like SAP Information Steward, SAP NetWeaver Information Lifecycle Management, SAP Master Data Governance, etc. All royalties are donated to Doctors without Borders. I’m planning to write a review of this book as soon as time permits.

Tags: , , , , , , , , , ,


  1. What is it like to work as an enterprise architect? | The Career Advisor - 11/15/2012

    […] Getting What You Need from Your Enterprise Architect […]

%d bloggers like this: