Posts Tagged ‘enterprise architecture’

The Artist Formerly Known as Enterprise Architect

February 25, 2011 Leave a comment
enterprise architecture framework
Is the role of EA evolving?

At the Enterprise Architecture Forum 2011 in San Francisco Forrester Research VP Gene Leganza asked, “Enterprise Architecture In The Year 2020: Strategic Nexus or Oblivion?” The role of the EA has always been nebulous.  “What do you do?”,  is one my least favorite questions in the world.  Good EAs must skilly combine business acumen, technology knowledge, risk management, process, excellent communication skills and alchemy to align technology resources to whatever will be needed to meet the future competitive goals of the business.

It is so important for EAs to be aligned with the business that a new trend is emmerging.  4% of enterprise architects report to a business executive, a chief operating officer, or chief executive officer, for example. 43% report to the CIO and 12% report to the CTO, Leganza said. The 4% is a new development.

Business decision makers are increasingly driving technology decisions and they need advisors. It is a logical move, but definitely introduces some messiness in the organizational hierarchy. Leganza suggested that EA role may split by 2020 into a technology architect and a business architect. While I can understand the thought process I think it is dangerous. EA that only business aligned or only technology aligned are simply not as valuable due to their biases.

Information Week explored this evolution in the EA role  in more detail.


Is There Room for RIMO in the Cloud?

February 22, 2011 Leave a comment

Recent industry analysis suggests that demand for remote infrastructure management outsourcing, RIMO, is increasing. Driven by aggressive budgets and growing technology demands, leaders are finding newer, more efficient ways to operate.  RIMO is a multi-billion dollar market; and, the growth is expected to continue. However, optimism about the RIMO market is not universal.  Read more of my latest article on Nearshore Americas.

Organizations Opening the Door to Open Source

February 11, 2011 Leave a comment
open source

Increasingly, open source is becoming an important part of the corporate software portfolio.

A recent Gartner study is confirming what many of us have long known – open source software (OSS) rocks. Enticed by promises of flexibility, innovation, lower cost and faster acquisition times, companies are increasingly adopting open source solutions to support their business processes. OSS is becoming pervasive. The benefits are compelling, but nothing in life is free, and despite popular perception, that includes open source software.

Read more of my article on TechAxcess

Cloud Standards: Bringing Clarity to the Cloud

February 9, 2011 1 comment

The cloud is, well everywhere.  Blogs, industry magazines, vendors and even television commercials seduce us “To the cloud.”  The latest reports by industry analysts indicate cloud computing is one of the top technology priorities for CIOs in 2011.  Given the rapid increase in popularity, adoption and vendors, it shouldn’t be too surprising that the momentum to establish standards for cloud computing has also increased.

Read more of my latest article over at

Oracle Offers Free EA Guidelines and Reference Architectures

February 9, 2011 Leave a comment

Despite Oracle’s recent antics with Java, maybe Oracle isn’t all bad. The company has released a library of of guidelines and reference architectures targeted at enterprise architects. The library includes more than 25 documents and 1,200 pages of enterprise architecture materials. The library includes:

  • Overview documents
  • Oracle Reference Architectures
  • Enterprise Technology Strategies for Service-Oriented Architecture
  • Enterprise Technology Strategies for Business Process Management

Oracle is providing the library free to registered OTN members.The EA IT strategies is located at

Five Trends In Enterprise Software

February 8, 2011 1 comment

The analyst firm that seems to know everything about everything in the world of technology, or at least plays one on the web, Gartner, has identified five trends impacting the enterprise software industry long-term. The firm is predicting the enterprise software market will surpass $253.7 billion in revenue in 2011 – not an insignificant sum by any measure. Where is all of this cash headed?

The enterprise software marketplace constantly changing and adjusting, but Gartner says globalization, implementation, modernization, socialization and verticalization, will be driving the industry long term. The Gartner study indicates:

  • Globalization: This encompasses market consolidation and technology convergence trends, as well as the connected society, vendor mergers, and acquisitions. Gartner predicts significant technology and vendor consolidation during the next several years will reshape the current landscape. During this period of market disruption, highly fragmented software markets will become more structured and marked by an extensive reduction of vendors. Even though organizations compete globally, localization requirements — including languages, cultures and laws — must be supported.
  • Implementation: How organizations procure and deliver software is being challenged with cloud-computing, platform as a service (PaaS) and SaaS, coupled with pervasive and mobile access. The demand for cloud-based solutions will continue throughout the next several years. Mobile solutions have led to the opening of many new industry-based market opportunities, such as mobile banking, mobile commerce and remote healthcare diagnostics.
  • Modernization: Enterprises continue to migrate to open-source software (OSS) and SOA as older applications and systems become more costly to upgrade and maintain. Aligned with the modernization trend, automating business processes and streamlining workflows continue to gain traction. Enterprises are expecting to provide significant resources in 2011 to upgrade all types of systems and software, ranging from personal productivity tools, to build-run-manage infrastructure software, to user-driven applications. Virtualization is a key modernization factor.
  • Socialization: Use of social media and networking continues to gain traction. In the trend of socialization, which includes personalization, collaboration and content in the context of user-defined activities, Gartner predicts that unified communications and collaboration will see increased adoption in 2012, and context-aware and presence-based computing will gain more traction in 2013.
  • Verticalization: This trend involves a cycle of horizontal software applications becoming more customized and catered toward specific industries. In deploying new software technologies, it is common for vendors to initially provide generalized technology that, over time, can then give rise to more industry-specific and line-of-business features. Examples are communications-enabled business processes and composite content applications.

In addition to identifying broad technology trends,  Gartner also noted that business intelligence, collaboration, content management, social software and supply chain management will be the top software growth areas in 2011. Given the recent velocity of solutions emerging in this space, it seems that vendors agree with analysts’ assessment.

A SOA Maturity Model

May 15, 2010 Leave a comment


Purpose and Scope

This describes proposed Service Oriented Architecture (SOA) Maturity Model that be can be customized for evaluating SOA maturity in your organization. The goal of the model is to provide a framework to evaluate the progress of an evolution to services orientation. Additionally, the model serves as guidance to develop an execution plan for incremental services adoption within an organization. Several existing models were consulted in the development of this model such as the open model currently being developed by the Open Group.

What is Services Orientation

Services orientation is NOT about creating web services. In fact, services orientation does not require web services technology; however, leveraging web services technology is tool for achieving some of the goals of services orientation.

Services orientation from a business process perspective is about defining discrete business processes/offerings and understanding how those discrete business processes can be composed into larger process or new offerings. For example, opportunity identification is a discrete business process that is part of the:

  • network formation
  • creating new client engagement
  • identify savings opportunity



Identifying discrete processes allows organizations deeply understand the processes, identify opportunities for optimization, and monitor the processes to ensure they are efficient. The more the underlying process is reuse, the more valuable these activities become.

Services orientation from a technical implementation perspective is an approach to designing, implementing, and deploying solutions such that a solution can be created from components implementing discrete business and technical functions. These components, called “Services”, can be distributed across geography, across enterprises, and can be reconfigured into new processes as needed.

Characteristics of Service Oriented Solutions

  • Component Oriented – Service oriented solutions are component oriented. Component orientation means that each service performs a cohesive and logical set of activities for a single concept. For example, a payroll service might provide functions such as issue W2s and issues checks or a data access technical service might provide functions such as persist entity.
  • Composability – Service oriented solutions support composition into new services and solutions without impacting the existing service implementation.
  • Platform and Location Transparency – Service oriented solutions do not require that services be implemented on the same technology platform or in the same location.
  • Broad Interoperability – Services oriented solutions should support standard protocols to ensure the highest level of interoperability.
  • Self Describing – Services should be self describing.  The interface to the service and its operations should be discoverable via meta-data, not out-of-band communications (e.g. document)
  • Message Oriented – Information is transmitted to and from services as messages. The focus in the definition of the interface and messages is in “what” a service does rather than “how”. The “how” is internal to the implementation of the service.

Business Benefits of Services Orientation

Service orientation has numerous benefits including:

  • Delivery Time and Cost – Knowledge transfer time is reduced within projects in a matrixed staffing model as resources transition between projects. If developers are trained on enterprise level shared services, the knowledge is transitive between projects. Further, each project does not have to go through the effort recreating  functionality that has been previously delivered. (see Evaluating Existing Assets for Reuse)
  • Business Responsiveness – Delivery of solutions through composition is faster than constructing solutions from scratch as higher levels of service maturity are achieved. This becomes especially tool as tools such as Enterprise Service Buses (ESB) are put in place that can mediate normally complex concerns such as service security and protocol variances across services.
  • Product Stability – Solutions that reuse services instantly gain the benefit of testing and tuning that has been performed. If the same functionality is developed over and over again each project has to potentially goes through the same learning and address the same defects.


Model Overview

A maturity model is a benchmarking system to measure progress toward a goal based on a set of objectives. A maturity model can provide a means for developing a transformation roadmap to achieve a target state from a starting state. The model defines the change, by area of concern, required for an organization to mature.

This maturity model focuses exclusively on services. It can be used as a standalone maturity model or in conjunction with a more broadly scoped maturity model such as CMMI. This model will allow a organiation to objectively assess if it is gaining the capabilities necessary to leverage services in an increasingly more sophisticated and beneficial manner. This model is a customization of the multiple services maturity frameworks such as those  developed by the Open Group (OSIMM) and the services maturity model developed by Gartner. It also recognizes some of the work done in SoMa by IBM.  It is organized in a matrix of seven disciplines and four maturity levels as illustrated below:

Stage 1Introduction Stage 2Spreading Stage 3Collaborating Stage 4Optimized
Business {Goals} {Goals} {Goals} {Goals}
Organization & Governance {Goals} {Goals} {Goals} {Goals}
Methods {Goals} {Goals} {Goals} {Goals}
Operations {Goals} {Goals} {Goals} {Goals}
Architecture {Goals} {Goals} {Goals} {Goals}
Information {Goals} {Goals} {Goals} {Goals}
Infrastructure {Goals} {Goals} {Goals} {Goals}

Table 1 – Maturity Model Matrix

The model details:

  • the benefits that can expect to be gained by matriculation to higher levels of maturity
  • goals for each level

The model is guided by the principles specified in the services Manifesto at

Maturity Levels

Maturity Level Concept

Maturity levels are used to categorize, into distinct stages, how wide and deep transformation has occurred within the organization. The services model is composed of four levels:

  • Initial
  • Spreading
  • Collaborative
  • Optimized

with level 1 being the least mature services adoption and level 4 being the most mature. Higher degrees of maturity are likely to lead to a higher degree of business and technical agility, but also require that the organization become proficient in an escalating set of organizational and technical capabilities.  The organization must be committed to making deep and wide-spread changes in not only in technology but also how business processes are described, implemented, and measured. While this does seem broad reaching every effort should be taken to make an “appropriate bite” for your organization. If your organization has process improvement initiatives in place a top down domain modeling approach might be the best way the starts versus implementing low-level technical techniques for reuse.

This model represents a middle out approach first developing some technical assets for reuse for common cross cutting concerns and then address more coarse-grained scenarios such as actual processes. I am not arguing this the only or even the best way to go for all organizations.

The table below provides a brief overview of the high level goals of each level. Subsequent sections will examine each level in detail.

Stage 1Initial Stage 2Spreading Stage 3Collaborating Stage 4Optimized
Business Goals Address Specific Pain Process Integration Process Flexibility Services for Sale
IT Goals Project Level Guidance
Core Service Standards
Some Shared Services
Service Design Standards
Service Reuse
Service Composability
Business Process Monitoring
Runtime Service Governance
Software as a business service
Event Driven Architecture
Service Scope Single Application/Project Single Business Unit Multiple Business Units Customers and Partners

Table 2 – Maturity Level Overview

Stage 1: Initial

The Initial maturity level is the first stage of the model. Level one is focused on:

  • Achieving component orientation
  • Project level services
  • Establishing a baseline enterprise level technical standards and guidance
  • Defining an approach to services delivery

Within this level, initial R&D activities to evaluate services technologies and techniques are conducted in a laboratory environment. The selected techniques are then applied within projects to solve specific problems. Additionally, it is at this level when basic standards and organizational structures required to support services are defined.

Stage 2: Spreading

In the Spreading level, shared services are developed using the standards and processes defined in the initial stage. This level focuses on services enablement within the boundary of single a business domain. In addition to actual service development, the infrastructure is put in place to more pervasively share services from project to project such as executing service governance processes and a service registry.

Stage 3: Collaborating

The Collaborating level is focused on leveraging the services developed for individual business domains to:

  • Compose cross business domain services
  • Identify business metrics to monitor on a real-time basis (e.g. number of  price comparisons per hour)

In addition, the services previously developed will be evaluated for overlap, redundancy and opportunities for consolidation.

From a services infrastructure perspective, the goal will be to implement tools that support runtime governance and management of services to improve configurability and location transparency which results in improved agility.

Stage 4: Optimized

The Optimized level is most sophisticated level of service maturity. It builds on the accomplishments of previous levels and focuses on service enablement externally to customers.


Disciplines represent different views or concerns of the organization


The Business discipline addresses the organization’s current business practices and policies, how business processes are designed, structured, implemented and executed.

Organization & Governance

The Organization & Governance discipline address the structure and design of the organization itself and the measures of organizational effectiveness in the context of services governance.  The Organization aspect is focused on organizational structure, relationships, roles and the empowerment necessary to adopt a service- oriented strategy. Governance is associated with formal management processes to keep IT activities, service capabilities, and services solutions aligned with organizational needs, guidelines, and standards.


The Methods discipline is focused on the methodology and processes employed by your organization to design, deliver, and manage service oriented solutions. Existing processes such as the Software Development Lifecycle (SDLC), operations management, and portfolio management will need to be updated to include services related check points.


The Operations discipline addresses the structures, processes, and assurances that must be in place for operational supportability of service oriented solutions. If a solution is not supportable are runtime or issues cannot be quickly identified and corrected reuse is unlikely even if the solution is functionality sound.


The Architecture discipline is focused on the structure of the architecture which includes topology, integration techniques, enterprise architecture decisions, standards and policies, web services adoption level, experience in services implementation, services compliance criteria, and which architecture artifacts are produced.


The Information discipline is focused on how information is structured, how information is modeled, the method of access to enterprise data, abstraction of the data access from the functional aspects, data characteristics, data transformation, handling of identifiers, knowledge management, business information model, and content management.


The infrastructure discipline is focused on the physical hardware and tools that are in place to support service oriented solutions.

Assessing Maturity

Maturity Goals Matrix

Stage 1


Stage 2


Stage 3


Stage 4


  • Define business domain prioritization

  • Business Service/Function Catalog
  • Process and Decomposition Models
  • Application and Component to Business Process Matrix
  • Domain Level Services

  • Composable Business Processes
  • Service to Business Process Matrix

  • Services for sale/use by external partners
  • Real-time business process metrics
  • Organization & Governance
    • Services COE Team Created
    • Pilot Services Governance Plan
    • Developers learn component oriented development skills

    • Implement services Governance Plan
    • Design time capture reuse metrics
    • Developers learn service oriented development skills
    • Refine SOA metrics including ROI
    • Runtime Service Governance Standards
    • Services Support Team
    • Runtime capture reuse metrics

    • Integrate Services Management into Product Management
    • Define vendor on-boarding and certification practices
    • Standardize Development Methodology
    • Reuse Evaluation Strategy Defined


    Service  Design Methodology  




    • Binary dependency management guidelines
    • Source management standards

  • KPIs and SLA Categories and Metrics Defined

  • Monitor KPIs and SLAs real-time
  • Service virtualization
  • Service configurability to support non-functional needs (e.g. translation between WS* protocols)

  • Runtime service governance
  • Dynamic exception and SLA management
  • Architecture
    • Service Development Standards and Guidelines



  • Service Design Guidelines
  • Service Reference Implementation
  • Establish architecture repository

  • Transaction Management Standards
  • Best practice guidance for event driven SOA


    • In scope data domains
    1. Domain Level Canonicals

  • Enterprise Business Data Directory
  • Enterprise canonicals
  • Data as a service/data federation

  • Industry canonicals
  • Analytics  as a service
  • Infrastructure
    • Shared Services Physical Environment (UIT, SIT, PROD)

  • Services Repository
  • ESB
  • Shared Services Physical Environment (PERF TEST)

    • BPM/BAM Middleware
    • Runtime Service Governance/Management Platform (with Policy Registry)
    • Security Federation Platform
    • Business Rules Engine
    • XML Firewall
    • Complex Event Processing Engine (CEP)

    Maturity Benefits Matrix

    Stage 1Introduction Stage 2Spreading Stage 3Collaborating Stage 4Optimized
    • Reduction in project delivery effort related to technical asset reuse
    • Improved cross project consistency
    • Increased developer knowledge or core component and service concepts

  • Increased ease of modification
  • Improved operational supportability
  • Reduction in functional defects
  • Project cost and effort reduction

    • Project cost and effort reduction
    • Improved business responsiveness
    • Improved application availability
    • Closer IT alignment to driving business value

    • Enhanced ability to proactively  optimize business processes  (due to availability of real-time process metrics)
    • New revenue opportunities
    • Project cost and effort reduction

    Assessment Process

    It is recommended that services maturity be assessed at least on an a bi-annual  basis. For each goal, by discipline the team should define and collect metrics and information to determine if has obtained the goal.

    Assessment Questions and Metrics