Project model
Dealing with formal deliverablesUsually we look into the deliverables of the project model – e.g. the requirements specification – and repeat or redefine the content. When the enterprise architecture is defined we also set out the frames and structures for e.g. the use cases/scenarios specified within the requirements specifications. Having a 3-layer model for the services and well defined boundaries between the services defines which types of use cases we must specify in the requirements specification. During this activity we agree upon formal issues like:
However often we find old habits regarding content and purpose of the deliverables. Often these habits need to be challenged or reassessed. Dealing with old habitsThe introduction of formal enterprise architecture processes in an organization calls for a reassessment of some of the deliverables within an IT project. However, it is beyond the scope of this article to walk through every deliverable in an IT project. So let us just take the requirements specification as an example. The content of a requirements specification can be – and has been – discussed and there are many answers to what the ideal content should be. We are not claiming to have the ideal answer but we would like to add a perspective that our experience tells us should be considered. Please try to pick up the following arguments. Traditionally a requirements specification is supposed to hold the requirements. We have another document for the solution – namely the design specification. It is generally understood that describing a given data-element with XSD schema is something you can do in the design specification and not in the requirements specification. But does this “rule” still apply in the SOA world? What is the purpose of EA or SOA? One of the basic ideas is to facilitate the reuse of messages, components, services etc. Let us assume we succeed in doing this. Let us assume that in a project 2 years ago we defined the entity “Contract” which we now want to reuse in a new project. Hence it is a requirement that Contract should be reused. Contract is well defined - described by an XSD. Now it does not make sense not to put the XSD into the requirements specification. Perhaps we need to remind ourselves of the purpose of the requirements specification? The purpose of a requirements specification is to hold the requirements of the organization/customer. If the organization has a requirement that a certain schema/data definition must be used then put that requirement into the requirements specification. There is no reason for keeping it as a secret until the design phase. Purpose of enterprise architectureIn any EA initiative we seek reuse. Reuse implies using something already defined. There is no point in not putting this into the requirements specification. Even if a given message is not yet defined, we should plan for reuse within our organization. This often implies that the organization has to decide on the content of a message. Hence the organization cannot leave it to the whims of any outside developer to decide upon the schema of a data entity. The arguments above might be a bit provocative. But try to consider the consequences when the primary objective of EA or SOA is reuse. It is our experience that once the organization has performed a few projects following the agreed EA framework, reuse will set in. The number of new messages will significantly decrease. In order to harvest the full potential of your EA efforts you should reassess your processes and deliverables in the light of intensive reuse. |
The project model used when conducting IT projects within the organization needs a revisit in the light of the findings done when addressing the