John Zachman Introduction to Enterprise Architecture

John Zachman gave a very good presentation on Enterprise Architecture and The Zachman Framework at The Open Group, San Diego, Feb. 2015. A transcript of the presentation (without visuals) is also available. The presentation is about 1 hour long.

It is my opinion that everyone that is interested in general management operations should take the time to watch this video.

Even if:

  • you think that Enterprise Architecture is a waste of time you will learn something
  • you think that Enterprise Architecture is an IT concern you will learn something
  • you think you know The Zachman Framework you will learn something

One of his final points that I have strongly believed in for many years is that Enterprise Architecture should become a General Management Operational Process and not simply an IT exercise.

The Concise Definition of The Zachman Framework by: John A. Zachman provides a quick overview of The Zachman Framework but I strongly recommend watching the video first.

A further discussion of single variable models can be found in Zachman’s article “Architecture Artifacts vs Application Development Artifacts.” At the time of this post it could be found online here and here.

Business Success and Technical Tools

Are you in a business support role? This is those roles that aren’t directly involved in selling, delivering, and supporting products and customers. For example, roles like information technology, quality, auditing, legal, procurement, human resources, and accounting.

Do you have any of your own projects, or, do you play a supporting role in “business” sponsored projects?

How are the goals for the project defined? Who is responsible for the outcome of the project? What metrics are used to measure success?

Business sponsored projects must have business goals. For example, implementing a software package is not a business goal, it is a functional goal – the function of Information Technology. Measuring product quality is not a business goal, it is a functional goal – the function of Quality. Employee evaluation and ranking is not a business goal, it is a functional goal – the function of Staffing. Functional goals can be successful and yet the project can still be a business failure.

Projects and goals must be defined and executed in terms of benefits to the customer. If the goal is to shorten the sales and delivery cycle then the sales force automation software is only a tool. Tools do not replace smart and dedicated workers. It is these employees that leverage the tools available to them to achieve their goals. The responsibility for success falls squarely, in this example, on whoever is responsible for the customer relationship.

The “The Secrets of Software Sucess” by Chris Dowse in CIO Insight magazine mirrors my experience over many years now. He doesn’t say it outright, but I will repeat what I have told many company executives with failing software projects. “The business must take responsibility for and own the success/failure of the business purpose for the software project.”

I believe that one way that this can be facilitated is to separate governance from implementation and support. A corporate level governance team should own strategic and politicized responsibilities like enterprise architecture, portfolio governance, and process automation.

The technology implementation and support team should provide the technology services and tools and protect the data (wherever it may be) in a utility-like fashion.

Business Process Mangement (BPM)

Business process management (BPM) is the study of the design and
execution of processes. A business process is a step-by-step algorithm
to achieve a business objective. Business processes are viewed as assets
to be managed, designed, and continuously improved to enhance business
agility and operational performance. BPM includes modeling, executing,
and monitoring business processes to achieve optimum outcomes.

Benefits of BPM:

  • help organizations move from being operationally focused to being customer focused
  • formalize existing process and spot needed improvements
  • help business leaders identify which processes can benefit most from becoming more agile
  • create a shared perspective on how multiple functions contribute to the entire end-to-end process
  • help organizations move from operational silos to become focused on the end-to-end process (more customer-centric)
  • facilitate automated, efficient process flow
  • increase productivity and decrease head count
  • allow people to solve the hard problems
  • simplify regulations and compliance issues

According to Andrew Spanyi (Spanyi, 4/2008) you know that you need BPM when:

  • Processes involve many complex steps
  • The business lacks process control and auditing features
  • Exception conditions are handled inconsistently
  • Transactions are plagued by high error rates
  • You can’t view and track all process-related data and documents
  • Information flows slowly or inconsistently across the organization
  • Disparate IT systems are in need of integration
  • Processes require manual paperwork
  • Work in progress can’t be traced across multiple departments
  • Reporting on work steps and end-to-end processes is cumbersome
  • Decisions take too long

A BPM system is a set of integrated technologies that enable
process stakeholders and users to model, execute, and monitor business
processes to achieve optimum outcomes. Complete systems include
technologies for managing all aspects of the business process; people,
machines, information, business rules, and policies. BPM systems are
process-oriented applications.

Benefits of BPM systems:

  • BPM initiatives place primary responsibility for process management on the shoulders of the business units – where it belongs.
  • puts the capabilities to design and manage processes into the hands of the business leaders
  • makes a process explicit – gives visibility of the end-to-end
    business processes and enables business leaders to make adjustments in
    real time
  • provides the ability to continuously optimize and improve the process
  • abstracts the business process flows from the underlying technology (separates process model from implementation)
  • can help break down application silos and automate more of the end-to-end process
  • provides greater leverage of existing assets, rather than simply making new software investments

Some best practices for BPM projects are:

  • highly iterative
  • eliminate project disconnects
  • assign a core team
  • select the right BPM system
  • embrace top-down discovery sessions
  • start with current state process model before making enhancements
  • immediate core team training

In the Building A Service Delivery Model for Enterprise BPM case study the authors discuss setting up a Center of Excellence for Business Process Management at Merrill Lynch. A lot of this is pretty standard but I liked how they grouped their requirements in a set of common themes and then carried these themes forward through the remaining phases. The common themes that they identified are:

  • Competency Analysis
  • Governance
  • Collaboration Improvement
  • Technology Improvement
  • Process Management

There are also a number of example templates that are useful if you don’t already have something in place.

(This information has been gleaned from a number of sources over time. I don’t have the exact sources for all of it but they include Gartner research, Forrester research, IBM documentation, and BEA/Oracle documentation.)

Enterprise Solution Architecture Migration Diagram

When you have multiple overlapping systems and want to develop and articulate a plan for decommissioning entire systems or functional parts of systems the diagram below is useful.

To show the migration plan, over time, you would have a current state version of this diagram and then additional milestone versions until the final version. In each version you would remove the systems or functions in the systems that would be decommissioned and add any new enterprise-wide or common applications.

ESA

Enterprise Architecture Goals and Conceptual Features

I believe that these enterprise architecture goals and conceptual features would apply to most businesses.

Enterprise Architecture Goals

  • Provide a robust and agile framework to build new composite applications and extend our core applications
    • Isolate external applications from core system stability and functionality issues and changes
    • Reduce development time
    • Ensure data and business logic consistency
    • Reduce infrastructure costs
    • Define IT services in terms of business functions and processes
    • Straight through processing – manage by exception
  • Engage and enable the business to manage changing business needs
  • Enable flexible and distributed service provisioning
  • Manage Data, Information, &  Knowledge as a Critical Corporate Resource
  • Conform to Industry Standards and Best Practices
  • Allow Federated Ownership of Systems

Enterprise Architecture Conceptual Features

  • Web-based User Interfaces
  • Service-Oriented
  • Event-Driven
  • Message-Based
  • Loosely-coupled
  • Layers of Abstraction
  • Composite Applications

IT Principles

Here are a set of IT principles that I have used in the past.

  • Business (mission, strategy & processes) drives the architecture
  • Information is a corporate resource and will be managed according to Information Policy
  • IT self-service capabilities delivered to expert business users
  • IT systems must support efficient, cost effective and timely responsiveness
    to changes in the business
  • A bias to buy application services and tools will exist where competitive
    differentiation is not a primary driver
  • Purchasing decisions will be aligned with architectural investments and standards for network, hardware, training, and software
  • Where feasible, business execution platforms will be consolidated to reduce
    costs and improve service
  • Operational tools will be consolidated and measurements will be standardized
  • A single system development life cycle (SDLC) and project management
    methodology (PMM) will be employed for all systems development efforts
  • Quality improvement practices and measures will be employed across IT
  • Up-to-date training and education will be continually provided for our IT staff

What IT principles does your organization follow?

Business domains and application fortresses

Business application functionality should be grouped together into business-domain-oriented systems.

These business domains are sets of applications and databases that are managed as units for business reasons and to increase IT system business alignment.

Each business domain is managed and controlled independently of the other business domains. This provides for a high level of cohesion with a single business domain (a good thing) and a low level of coupling between business domains (also a good thing). Each business domain can have its own level of access and security and service levels, for example, based on the requirements of the business.

Communication among the independent business domains is through contract-based business services.