It is always about well-defined requirements stupid. Building or choosing out-of-the-box software products like an ESB within the company's SOA strategy can be very well supported by a number of requirements distilled from the QUINT2 ISO model:

Functionality: Suitability, Interoperability, Compliance, Security, Traceability
Usability: Operability, Customisability
Efficiency: Time Behaviour
Maintainability: Testability, Manageability, Reusability
Portability: Adaptability, Replaceability

This is the selection from the complete QUINT2 model. It does not mean that other requirements are not important, but usually less than these. If you fill out these requirements properly, which is still a daunting task, then you will have done pretty good requirements gathering. Besides these aspects, there are also security requirements: availability, integrity and confidentiality which should always be considered.

How do companies usually choose such products?

Many of the customers I came across or heard about are choosing SOA products more or less based on vendor reliability and their support. Some of them enthousiastically prepare the proof-of-concepts, which are requested more for political reasons than to objectively see if the product works. If this would be a good way of choosing such a product - even with properly executed proof-of-concepts - then all these companies are wasting their money. It would be easier and cheaper to ask an independent company to periodically do an extensive research and simply buy the results.

But I'm afraid it does not work like that. The problem is that each company has specific needs, which brings us again to the QUINT2 model.

How to define these requirements?

Instead of explaining what requirements gathering is all about, I'll mention only the aspects specific to SOA.

A difficult problem in gathering requirements for SOA products is that stakeholders (especially business people) cannot associate their world with the SOA world (BPM, middleware, infrastructure,...). The QUINT2 model can help by having a workshop about these "ilities" and explaining and matching their definitions to the specific situation. E.g. interoperability is a capability to integrate with other systems. The questions behind it are: what are the future plans (e.g. integration with internal and external parties), what is the type of integration on process / business level, and so on. The answers give you the material to make these ilities specific and quantified.

A properly defined integration architecture could play a crucial part in this process. This architecture is also distilled from business goals and requirements from the projects needing SOA. I find two books the most helpful in this architecture process: Enterprise Integration Patterns and Next Generation Application Integration. The advantage and goal of an integration architecture is to simplify and explain the world of integration by linking their business requirements to choices, risks and consequences in the SOA / EAI world.

Conclusion

Gathering requirements with help of the QUINT2 model in order to choose SOA products is a daunting task, but very important. It helps you choose the right one. It is funny to see that some customers find out that they don't need products like an ESB or a BPM suite at all. But even more important, you will know what to do with them once they are installed.

Filed under Requirements Management, SOA | 1 Comment »