Enterprise Architecture Tools: Why are IBM, HP, Microsoft, CA and others absent?

Enterprise Architecture tools are often used to analyze and optimize the portfolio of business strategies, organizational structures, business processes, tasks and activities, information flows, applications, systems, and technology infrastructure.

Many of these tools have been designed with different architecture goals such as modeling, storing, managing and sharing information.

These tools can be classified in two main categories: EA repositories, EA-modeling suites (Business & IT) including some EA models.

Choosing a category depends mainly on the approach toward:
· EA top-to-bottom approach
· EA bottom-up approach
and the relationships with existing development and modeling tools.


Looking at the various acquisitions from big names these last years and the increasing interest in IT Governance, we observed several vendors trying to extend their tools portfolio going from modeling to service management, from project management to portfolio management.

IBM acquired in 2002 Holosofx, a business process modeling capabilities product to extend Web sphere Business Integration which then was re-branded to Websphere Business Modeler, a component for the modeling of a Business Architecture. CA acquired in 2005 Niku’s Project Portfolio Management (PPM). HP acquired in 2006 Mercury and Peregrine, companies having IT Service Management, Project Portfolio Management (PPM), and SOA Governance solutions.

Project Portfolio Management and Enterprise Architecture

PPM and Enterprise Architecture should be integrated in some way. All investments which support a Business strategy should be organized. A categorization model has to be used, followed by an evaluation and a prioritization. Once approved, the investments or demands become projects. But, how to decide when and how to make changes? How do we understand what can and can not be changed? What are the opportunities?




This is where the impact analysis and the “What if” scenarios enable to analyzethe company’s portfolio and assess the business contribution of each proposal, project, or application to an entire portfolio which needs also to be governed and managed.

An investment, a new demand should also be validated against an Enterprise Architecture. What are the impacts on the Business Architecture, the Business Processes? Does that make sense for a company to add new layers of information to an existing Information Architecture? In the context of a new solution, how does the new application affect the existing Application Architecture? Same thoughts apply on the technology architecture.

Very often Portfolio Management teams do not take into consideration these issues and may only focus on real-time visibility into resources, budgets, costs, programs, projects, and overall IT demand, but without considering impacts on the architecture.

Mature IT Governance would consider a strong interaction between a PPM team and an EA team. Once validated, an investment or a demand should be routed to the Enterprise Architecture team (can vary on the size and the scope), which add value to the first level evaluation. After a second level validation, the EA team using preferably an EA tool where specific architecture views and viewpoints have bee documented, is in a position to deliver recommendations to the PPM team.

We then go back to the company’s PPM process which adapts if necessary the budget, the costs, the resources and the program. There can be situations where the impact analysis detects side effects, or identify alternatives (may be for example the re-use of existing functions), or recommend to abandon the initiative.

Some companies which have implemented an automated process with a PPM solution would be tempted to also integrate the activities related to an Enterprise Architecture impact analysis.

Enterprise Architecture teams often use tools but rarely in an integrated way with the customer or other teams such as a PPM team. The kind of tools like Mega, Casewise, Metis-Troux technologies do not integrate yet with PPM solutions. Eventually we can consider an evolution in that direction from Telelogic which started a while ago to integrate Popkin with DOORS, the latest being maybe more a Demand Management solution than a PPM solution.

So now where are the IBM, HP, CA, and others?

Wouldn’t that make sense to use the Rational RequisitePro with Rational Portfolio Manager integrated with an EA Tool? Wouldn’t that make sense to have HP-Mercury ITG integrated with an EA Tool knowing that Systinet is an SOA governance platform and SOA surely linked to an EA program? Wouldn’t that make sense to have CA-Niku integrated with also an EA tool?

With all the small EA vendors proposing standalone products, there is a high chance that the “big names” will consider new acquisitions and the integration of EA solutions.

The Relationship Between IT Service Management and SOA

The Open Group Enterprise Architecture Practitioners Conference Paris, France

April 23-25 , 2007

STREAM #15: SOA Frameworks and Standards

Wednesday April 25 11:30 – 12:00

The Relationship Between IT Service Management and SOA

Serge Thorn, Director IT Research & Innovation (Switzerland)

Synopsis:Is IT Service Management an emerging subset of SOA? There is a high level of correlation between success at SOA and commitment to ITIL. ITIL is a standardized approach and series of documents that are used to aid the implementation of a framework for IT Service Management. This customizable framework defines how ITSM is applied within an organization, covering processes such as service desk management, incident management, problem management, configuration management, change management, and release management among others.

Service oriented architecture is an architecture that allows to loosely couple capabilities that can be described as reusable services to support a business process. Processes such as availability management, change management or release management "are just business processes that are particular to IT". We now use this service-oriented architecture to link the business processes associated with IT, with the technology components that make up the IT infrastructure to an integrated platform that includes a configuration management database, an enterprise service bus, and a process orchestration layer. So we can think of IT service management as another use case or usage scenario for SOA. This session will cover XXXXX's roadmap and reflections in these two domains.

13ème Congrès Romand du Management de Projet

Atelier 11 : La gestion de projet et ITIL : deux mondes opposés, complémentaires ou intégrés ? présenté par itSMF (Serge Thorn)

Jeudi 12 avril – 11h20 à 12h00

Complémentarité des processus de Project management et de Service management :

• Intégration de la gestion de projet dans une logique de "Gestion des changements"
• Intégration du recueil des besoins dans le Service Level Management
• Impact de la gestion de la demande sur le Portfolio management
• Comparatif des processus de prise de décision et de la gestion des risques.

Service Level Management and SOA. more confusion?

Service Level management in an ITSM context

Everyone into ITSM may use the Service Level Management process to maintain and improve IT Service quality through a constant cycle of agreeing, monitoring and reporting to meet the customer’s business objectives.

Service Level Management is the name given to the processes of planning, coordinating, drafting, agreeing, monitoring and reporting on SLAs, and on the on-going review of service achievements to ensure that the required and cost-justifiable service quality is maintained and gradually improved.

One of the activities related to that process, is the creation of a Service Catalogue which was subject to another post: “Service Catalog, what do you exactly mean?” where I tried to distinguish the different types of catalogues when we refer to either an ITSM or an SOA environment.

Most of the time companies which have implemented a service desk have a SLM module which allows defining different kinds of level agreements:

• Service Level Agreement (SLA): Which are written agreement between an IT service provider and the IT customer. SLAs are normally used for internal customers
  
• Operational Level Agreement (OLA): Which are agreement between two internal IT areas/departments e.g. Network Management and Operations
  
• Underpinning contract: Which are contract between an external supplier providing services to an IT department
  

Many vendors have dedicated modules which manage the SLM lifecycle with requirements collections, monitoring, escalation, and various dashboards. These modules are obviously linked to other ITIL processes and information is kept in the CMDB. Among various solutions we have different SLM modules from HP-Mercury, HP-Peregrine ServiceCenter, CA Unicenter Service Assure, BMC Service Level Management, Assyst for Service Level management, Expertdesk.

These solutions allow managing the end to end SLM process in an efficient manner through an ITSM view and sometimes the content is routed to a Business Service Management solution or specific modules managing SLAs in dedicated dashboards such as Tivoli Service Level Advisor among other system management solutions.

Service Level management in a SOA context

In a previous post I was referring to one of the intersection between ITSM and SOA. “Amberpoint proposes a module to manage web services, their performance and availability. It can monitor failures, send alerts, display useful information related to problematic web services, automate performance and so on.

HP Mercury Systinet 2 has a module title Contract/Consumer Management which promotes trust between consumers and providers by facilitating service-level agreements and other terms and conditions that bind these two key stakeholders.

Progress Actional Looking Glass provides dashboard and reports which define, sort and prioritize by business or IT metrics (customer, transaction or service type). SLAs are also monitored, managed, measured and alerts are generated. We can also easily monitor and report on SLA's for a specific customer or class of customer such as gold, silver, etc.

For some consistency we should differentiates SLAs in an ITSM framework from SLAs in a SOA. For these reasons a good thing would be to create a new acronym: WSLA for Web Service Level Agreement!!

A WSLA could either be attached to a specific service or to a composite service. WSLAs should then be linked to SLAs. An end user does not have to know what the underlying architecture of his applications is. The Service Level Manager (if such a position exists…) has to negotiate with the customer SLAs. If an IT service is based on various technologies including SOA, he should take into considerations OLAs, Underpinning contracts and WSLAs!!!

WSLAs could also be attached to Underpinning Contracts is web services are either 2rd party services or hosted externally.

Most of the SLM activities remain the same however some of them may differ:

The Service Level Requirement activity will have to be taken into consideration the definition of the WSLAs. It will not be necessary to specify to the customer the underlying technology.

The building of the Web Service Catalogue is different from the Service Catalogue and probably the responsibility should be shared between the SLM manager and the SOA experts.

The SLAs creation and review taking into consideration OLAs and UCs should also consider WSLAs. If possible a hierarchy should be built.

Monitoring should be done at two levels:

• At the SOA level (eventually in SOA center of excellence or an operation dedicated team


• At the ITSM Level (the Service Manager should have a global view on all IT services)

Coming back to Service Level Management and solutions available in the Service Desk arena, companies should be able to only deliver one and only one SLA per service and monitor it. IT and business dashboards should aggregate all underlying categories of SLAs. In other words SOA Governance vendors should be able to provides APIs to upload data related to WSLAs into any IT Service Desk/System Management solution covering the SLM process.