Requirements Management and Enterprise Architecture

I was describing a while ago the relations between Requirements Management and other types of user’s demands.

Let me restate my definition of what that is. Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project. The project could be for a new consumer product, a web site, a system or a software application. In all these cases, the five classes of requirements should be represented.

The objective of the Requirements Management activity is to define a process whereby requirements for Enterprise Architecture are identified, stored, and fed into and out of the relevant Enterprise Architecture development phases. As such it forms part of the activities and steps carried out in each of these phases though it is not referred to implicitly in any projects I have managed.

(Requirements Management is also a discipline for both Quality Management (ISO 90001:2000) and Project Management (PMI)).

Target architecture must be based on credible assumptions about future business requirements. Getting these future requirements is not a simple matter of asking business management for them, and analyzing them is not the linear technique used to develop the design for a project. Instead, we have to use a combination of requirements aggregation and scenarios to gather and analyze long-term requirements. This will lead to more credible architectures with appropriate flexibility and evident business value.
For ease of use, it is convenient to think of requirements as belonging to a type.

• Business and Functional requirements

They are the fundamental or essential subject matter of the service or product. They describe what the service or product has to do or what processing actions it is to take.

Business Cases or Scenarios should be used as a useful technique to discover and document these requirements.

Project and Portfolio Management (PPM) addresses the decisions regarding what projects to undertake, with what priority, and in what sequence. Before a project has gone through the necessary requirements definition activities, its scope is based on high-level requirements derived from business drivers, plans, and needs. If these requirements are viewed in isolation, then solutions will be defined in isolation, and they will ignore synergies or dependencies between projects and undervalue foundational projects that provide capabilities that can be leveraged across future projects. Business Requirements also have to be a source for Project Management methodologies.

• Non-functional requirements

They are the properties that the functions must have, such as performance and usability. These requirements are as important as the functional requirements for the product/service’s success.

• Project constraints

These are restrictions on projects due to the budget or the time available to build a product or service.

• Design and architecture requirements

They impose restrictions on how the product/service must be designed. For example, it might have to be implemented in the hand-held device being given to major customers, or it might have to use the existing servers and desktop computers, or any other hardware, software, or business practice.

• Project drivers

These are the business-related forces. For example, the purpose of the project is a project driver, as are all of the stakeholders-each for different reasons.

• Project issues

They define the conditions under which the project will be done. The reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements as input when managing a project.

• Testing requirements

It is recommended to start testing requirements as soon as we start writing them.
We make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. If a fit criterion cannot be found for a requirement, then the requirement is either ambiguous or poorly understood. All requirements can be measured, and all should carry a fit criterion.


Requirements Management and Enterprise Architecture cannot be dissociated.

Some vendors have perfectly understood the need of integrating this, such as Telelogic and the need to share a common metadata repository.

With that solution, there are possibilities to go from requirements, to enterprise architecture, to systems implementation and design, with tightly-coupled, bi-directional integration between DOORS (their requirements management tool), and Systems Architect.

IBM has it’s own requirements management solution but has (not yet) an enterprise architecture solution. This may change with the on-going acquisition of Telelogic, but I haven’t been really able to understand IBM’s strategy yet. Is this only a question of absorbing another market or a willingness to offer a full Enterprise Architecture suite in the Rational catalogue? (Requisitepro being obviously an issue….).

The HP approach seems to be the how to integrate the different application coming from the former Mercury and Peregrine world. HP PPM (and HP Quality Center for testing requirements). Their current approach is to use the Demand management module in PPM to manage business requirement at business level and using the module in Quality Center to specify the requirements at technical level to translate them in test case. Nevertheless, HP does not have any Enterprise Architecture solution.

The re-birth of Enterprise Architecture?

Sadly enough, Enterprise Architecture has always been considered as a side IT Governance component and few big names were proposing services around products. Why? Simply because the IBM and HP like did not have any product offering…IBM always claimed that they were into Enterprise Architecture but they always tried to sell their Rational line of products without really understanding what is EA all about…. Probably when acquiring all Rational products, there would be a chance to do EA, but at what effort, what level of integration and also at what cost? Modelling processes with Websphere Business Modeler is still a techie activity and there were no indication that Business Analyst would be able to use such a tool. Very often business people were rather considering using Mega or Aris from IDS Sheer. HP also on its side was never per formant on IT Governance and acquired Peregrine and Mercury, for Service Management, Project and Portfolio Management. Enterprise Architecture has never been on their agenda, despite the fact they sponsor the Open Group. This may change…

In a recent post I was wondering why these companies did not take into consideration companies such as Telelogic, Casewise, IDS, Mega, Troux and others. My view was that in the next 12 months the market landscape would change and most EA companies would be acquired.

This has just been confirmed by IBM who acquired today Telelogic. Telelogic propose two components: DOORS and the ex-Popkin System Architect. Requirement is at the center of Enterprise Architecture and the Telerate offer was really appealing.

Now with IBM a few questions have to be raised:

• What’s going to happen with Requisite Pro and DOORS? These two products have similarities.
• What about Websphere Business Modeler and the System Architect process modelling tool? Same issue.
• How will Telerate integrate with the Tivoli CCMDB (Enterprise Architecture Artifacts and CIs). An Enterprise Architecture Repository should be maybe an instance of a CMDB.
• How will be integrated WSRR with the SOA modelling of Telerate?
• How will RUP for SOA /SOMA) fit the various EA framework supported by Telelogic?

Will IBM start to really propose professional services around Enterprise Architecture and support TOGAF as an open Framework among others?

Until now it has not been the strength of these well known companies to provide a consistent roadmap in terms of integration. As another example HP is doing a poor job in terms of integrating Mercury and Peregrine (the roadmap is absolutely unclear in terms of UCMDB.. and there are no indication how redundant service management functions between Mercury and Peregrine will be managed). Different contacts, different interpretation of the account managers…

Will IBM be able to better integrate their suite of modelling and architecting products? Will they be able to provide roadmaps, strategy and clear directions?

With this announcement there is a high chance that competitors such as CA, HP, Microsoft and others will soon start to consider Enterprise Architecture as a new source of income and a way to sell new products. Watch the space for acquisition! That story will be similar to the one related to the auto-discovery tools market and CMDB.

If most of the big names will soon have an EA offer in terms of products and service, this will launch a new wave of EA projects and will help standardization organization to better promote EA initiatives!

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 CMDB Initiative..”, but where is the evolution?

Late April, a group of system and service management vendors decided to propose a standard related to a repository for IT assets, and their configurations items change over time.

In other words, BMC, Fujitsu, IBM and HP decided to create a model for a CMDB which would allow storing information such as desktop and laptop client images or configurations, servers, storage pools or networks and so on.

Very often information is spread among various sources and no standards exist on how to exchange meta data from all these potential sources of CMDB information. Today, the CMDB interfaces that exist are all proprietary, which is the problem that this group wants to tackle.
This working group will issue a white paper within the next month that will spell out their initial goals in more detail. And by the end of the year, they hope to have a draft specification proposal, at which point they hope to formalize the process by choosing a standards body.

But is that enough?

Focusing on data exchange is fine but shouldn’t they also consider the CMDB Meta data and propose a common model eventually re-usable by third parties?

All vendors’ CMDB have their own Meta model and as from now I have never seen from any vendor a roadmap related to the repository. As an example, with the acquisition of both Mercury and Peregrine, HP initially announced the migration from the HP Openview Service Desk, to Service Center, and now has announced that next CMDB would be the one from Mercury, which is in fact…Appilog… (An acquisition from Mercury). So what!

There is a need for a “next generation CMDB” for the following reasons:

- BPM based on a SOA architecture invoque IT components (software on hardware…) and we should have a link between a Business Process and the underlying Cis. A CMDB should also be process based.
- Relation is important that’s for sure but dependencies is another key topic. How does infratructure relates one to the other, how information relates one to the other, how physically components relates one to the other, how does application code relates (Cendura acquired by CA is maybe one of the only company which deleivred that capability) etc… A CMDB should be also able to add dependencies on the top of relationships.

This initiative will help the concept of federated CMDB and information exchange but will not really look at today’s requirements… A unified Meta model could be an interesting initiative for these vendors as this would create a new generation of unified Service management/Business Process management solutions.

Does an IT ERP make sense?

Despite the fact that some software vendors companies such as ITM Software are considered to deliver such a solution, I would rather qualify this product as a Project and Portfolio Management solution such as Primavera, Artemis, Mercury and others.

Many companies have a wide range of non integrated solutions covering several aspects of IT Governance such as:

-Project Management
-Portfolio Management
-Time Management
-Service Management
-Enterprise Architecture
-System Management
-Security Management
-Asset Management
etc..

For each of these components some of them have associated processes but no real touch points between them and the visibility is quite difficult to get in terms of IT Service quality. Some companies passed certifications such as ISO 9000, ISO 27001, went through COBIT, and are ITIL based etc... But from my various observations, they do not have a consolidated or integrated view of their IT Services which would contribute to the improvement of Business IT Alignment.

Very often, top management including the CIO ask for IT to deliver Dashboards where we can have in real time indicators (KPIs) on the department performance and then be able to benchmark against competition.

Among existing solutions we have, IT Governance suites such as Mercury ITG or CA Clarity, Service Management platforms such as Peregrine Service Desk, Remedy, CA, HP, Asset management solutions, and finally Time Management product. In the system management landscape, Tivoli, CA Unicenter, and lots of various monitor solutions to manage networks. Fiinally, Enterprise Architecure is often covered by companies such as Telelogic (Popkin), Casewise, Metis solutions etc…

My experience would be to claim that first we need to re-engineer the process, have integrated flows between domains in order ro be able deliver these dashboards, finally avoid duplicated activities within an IT Department.

As no vendors today is able to deliver such an “IT ERP” (but probably HP, IBM and CA will be able to deliver this but nor before a couple of years…), an alternative would be to consider services around these platforms and then from a portal, orchestrate those services, provide results in various dashboards. Obviously if we had an integrated platform, that would be easier.

For the time being, mash-up applications are probably the only way to produce an IT ERP.

Will Service Management solutions become SOA Governance platforms?

As a starting point, let’s re-define what a Configuration Management Database (CMDB) is… A CMDB is a database that holds a complete record of all configuration items (CIs) associated with the IT Infrastructure, software, hardware, including information about servers, storage devices, networks, middleware, applications and data, i.e. versions, location, documentation, components and the relationships between them.

Configuration Management which is one of the main ITIL processes requires the use of support tools, which include a CMDB. Physical and electronic libraries should be set up parallel to the CMDB to hold definitive copies of software and documentation.

Until now, several vendors have provided through their Service Desk offering, and out of the box CMDB which in some case could be altered. Among these vendors we can find, BMC-Remedy, HP, Peregrine (now HP…), Axios systems, Computer Associates, Mercury (now HP…), IBM, and many others.

Last April, some vendors like CA, BMC, IBM, and Fujitsu announced they would work toward developing "an industry standard for federating and accessing IT information" that would ideally integrate communication between disparate configuration management databases.

CMDBs have become one of central elements of enterprise IT management, so a standards-based approach to this critical functionality is necessary and valuable.

Looking at SOA and the way we define composite applications and services, we definitely need to build the latest on the top of existing IT Infrastructure, software and hardware. In other words, a CMDB could also be used to manage the catalogue of SOA Services!

I would be tempted to think that in the next 2 years, a CMDB will be a modular component, usable by either Service Management solutions, and/or SOA Governance products. A CMDB could become a sort of “plugin” available from various vendors with sets of APIs, and why not web services.

SOAs are distributed computing plans where companies often situate Web services and reuse code and other assets to create efficiencies. Vendors like IBM, Microsoft, BEA, Oracle, and Mercury are creating SOA infrastructure platforms to speed information exchange between different computing machines. A few months ago, prior to HP acquisition, Mercury acquired a SOA company named Systinet. This acquisition strengthened Mercury's position in the high growth SOA (Service-Oriented Architecture) market by giving the company leading SOA governance and lifecycle management products.

An integration point should be between the SOA metadata repositories and a configuration management database (CMDB) to manage the lifecycle through to operations. If HP considers the range of acquisition they recently did with Peregrine, Mercury...and Systinet…there would be a high probability, this integration occurs!

Another observation on this future integration is potentially visible with IBM. IBM released recently a CMDB titled Tivoli CCMDB, and also launched a management and security solutions for managing SOA based applications, IBM launched last April IT Service Management platform.

The IBM IT Service Management platform manages SOA based composite applications. It is supposed to offer an approach to defining a framework and solutions for IT service management, including extending self-managing autonomic computing to IT services.

“Tivoli CCMDB uses a Federated model that allows it to be implemented on top of an existing sources of IT data, and serves as an authoritative source of data for configuration items, their relationships, so that when a change needs to be made to any of the IT components, one can understand the impact of that change on other related components. IBM's ITSM platform along with, IBM Tivoli security and compliance products like Tivoli Access Manager and Tivoli Federated Identity Manager delivers a complete end-to-end solution for the "manage", "secure" and "compliance" of distributed SOA applications.”

IBM and HP are two companies which will probably compete in both IT Service Management and SOA. They probably understood the synergy between the two worlds, and we can predict a future new generation of CMDBs, modular, accessible from web services, and used for several companies needs: Service Management and SOA Governance.