In Smart projects, functional requirements are modeled using smart use cases. These smart use cases are identified through the businesss processes that will be supported by the software to build.
Services oriented architecture and smart use cases¶
In projects that are realized using a service oriented architecture, we define two types of smart use case diagrams:
- Service consumption. Smart use case diagrams that range all interaction between the end user and the software, up to the point where middleware or individual services, gets called. These diagrams are initiated by (mostly) human actors on the lefst side of the diagram, representing the actual users. On or several (if smaller) user-goal level use cases cover the execution of the business process. Any number of sub-function level use cases can be associated, some of those likely middleware or services smart use cases on the right side of the diagrams. It is considered good practice to also model the systems that are called through these use cases as actors, also on the right side of the diagram. These are called supporting actors.
- Service provision. Smart use case diagrams that start at the middleware (modeled as initiating actors, on the left side of the diagram) and the called service as user-goal level use case. Any associated services, mostly executed in some back end, such as a SAP CRM module or Microsoft Axapta, are modeled as sub-function level use cases.
===Discovering reusable services===
Each of the smart use cases that model a specific (business) service, are potentially reusable. We advice to investigate the following briefly, already during a Scope typed iteration:
- Ready to use. The desired service is already available and can be called without further tuning.
- Paramaterize. A service exist that almost performs the desired functionality. Writing some simple parameterization or perhaps a small wrapper/adapter is sufficient to make the use case work.
- New. The desired functionality is not present in the back-end application. It needs to be built completely new, perhaps reusing other services.
Once the service smart use cases are characterized using this technique, the estimates for the project can be improved.
Furthermore, a well established smart use case service model is a very good basis to investigate the impact of implementing new processes. During a recent Smart project that implemented a service oriented architecture at a larage international transport organization, we had already implemented an important process during the first four iterations of the project. During the fifth iteration, the customer asked for an impact analysis for an additional, but very different process.
During a short workshop following his request, it appeared that most of the services required to implement this process, were already available, because we had implemented them in the previous process. The impact analysis showed that we only needed to implement four additional (service) smart use cases, at a total of 16 smart use case points. The total process ranged over 60 smart use case points.
Sander Hoogendoorn
Check for connectivity
In projects that work on or implement a service oriented architecture with many different systems in it, connectivity is a hot issue. Quite often, arranging connectivity is not easy. Your will have to go through layers of burocracy, and many change request forms, before reaching the party that has to deliver the actual connectivity, not seldom outsourced to another company or even to another country. Altough the actual work, such as opening up a specific port between the enterprise service bus, and a back-end system, might not take more than a few minutes, the whole procedure might take weeks, due to prioritization of the maintenance organization.
This red tape can hinder project progress enormously. When you try to implement a (service) smart use case in the third iteration, requesting YAGNI connectivity at that point in time is not enough. You will have to have asked for connectivity much earlier in the project, depending on the amount of red tape, you will engage.
We therefore recommend to check connectivity needs at the same time (during a
Scope typed iteration) service smart use cases are investigated. Do we already have a connection open to this particular system? If so, are we allowed to travel the connection? If there no connection has been established, request for it immediately - or do so as soon as the project moves into
Realize iterations.
At a project that ran from March 1 to July 1, we requested connectivity from SAP middleware to a PeopleSoft back-end system, at the very start of the project, during the Scope iteration. Because of the high work pressure, the maintenance department could not immediately service our request. Although the department admitted that the actual work would not take up more than 5 minutes, the expected delivery date was set at July 17, about 2 weeks after our project needed to be delivered.
Sander Hoogendoorn