In any project, and especially in projects that run under a tight schedule – as most projects do these days, it is helpful to list all elements that can possibly be (re)used to crank up your project, such as guidelines, documentation templates, existing components, (web) services, frameworks. This can best be done early on in the project, traditional or agile. The agile process Smart reserves this activity for early iteration, typically branded Scope iterations. In Scrum I would place this activity in what is nowadays referred to as Sprint 0.
This is also the moment to see (but not to elaborate) where your organization’s services are located, whether they can be reused as is, or require tuning (parameterization according to SAP) to be used in your project. A simple technique that works quite well is to go through all smart use case diagrams, and find out if re-use is possible, not only for front end smart use cases, but even more so for identified services.
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, and service provision. In most service oriented projects eventually both types are combined to give the customer a good overview of the processes at hand.
Service consumption smart use cases
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 left 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. In the diagram below such middleware smart use cases are colored red.
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 (left out for esthetic reasons in the diagram below).
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.
The diagram below shows a typical example of a service provision smart use case diagram. In this diagram, the purple ovals represent SAP XI middleware, which is triggered by a smart use case that is model on the left of the diagram, and represents a front end system. All green and slightly yellow smart use cases represent individual possibly reusable services.
Ready to use. The desired service is already available and can be called without further tuning.
Parameterize. 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.
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:
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 large 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.
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 bureaucracy, 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. Although 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.