Service Taxonomy and Requirements

Having seen how organizations can struggle with it, convinced me that before you start to capture the requirements of a serious amount of services, you rather have a proper classification scheme identified up-front. A service taxonomy as such a classification scheme is called, is important for a couple of reasons:

• The requirement attributes are likely to differ somewhat between classes, making that you might want to use different templates,
• A service taxonomy supports a proper positioning of services in the application and technical architecture,
  
• A service taxonomy supports a proper layering of services.

There is no single best taxonomy, as it depends on aspects like the number of services, and the nature of those services. However, a good starting point could be a classification like the following one.

First of all the following (more or less atomic) classes of services can be distinguished:

Business Services that are recognized as such by the business, like Retrieve Customer Profile, Print Order Confirmation.

Data Services that query or store data, like Retrieve Customer, Retrieve Customer Orders, Update Order.

Application Services, being all other services, like Print File and other 'utility' services.

The above classes concern atomic services, meaning that the services have a restricted, clear responsibility and therefore in principle are re-usable. When used in the context of use cases (or business processes) they typically will not cross steps.

Whenever applicable, you can also recognize Process Services as being the type of services that deal with service orchestration. Process services typically have a specific use case / business process as a scope. That use case can be a user-goal or summary use case (spanning multiple lower level use cases).

Batch Services are a specific kind of orchestration services that process multi-record messages in an asynchronous way.

Other Taxonomy Aspects

Your taxonomy can leverage more than one kind of classification, for example one that organizes business and process services by business domain.

Also different levels of services could be distinguished. This is where we talk about service granularity. For example, a higher level data service Retrieve Customer Data can consist of two lower level services Retrieve Customer and Retrieve Customer Address. The level of a service won't have much impact on the way you specify it functionally though. Also, specifying finer grained services is more likely to be the subject of analysis and design rather than requirements definition. The discussion about service granularity for requirements definition is likely to be that of user-goal versus summary use cases.

Be aware that the taxonomy you use during requirements does not necessarily need to be 1:1 with the one that is used for analysis and design. The meta-requirement for the taxonomy used during the requirements definition, is that it should be recognizable by business people. There should be a clear mapping to the taxonomy that you will use during analysis and design, though.

Generic Requirement Attributes

The requirement attributes of all service could consist of the following:

• name
• purpose (one, two sentences max)
• description (what does it functionally, i.e. without getting technical)
• type (within the taxonomy)
• triggering events
• pre-conditions
• post-conditions
• synchronous/asynchronous (request/response vs fire & forget)
• message format in
• message format out
• list of values (for attributes where applicable)
• transformation
• validation of incoming message
  
• list of (logical) errors that can be the result
• metrics
• business indicators (e.g. to collect BAM metrics)
  

Typical standard pre-conditions (that you might decide not to specify but capture as an architectural principle) are:

• consumer has been authenticated and authorized to use the service
  
• message format in complies to the XSD, meaning failing to do so will result in technical error

Message format in and out have the following sub-attributes:

• structure
• attribute names
• data type
• format mask
• mandatory

Attributes can also have a list of values that applies. List of values can be static (i.e. a list of fixed values, typically implemented in XSD) or dynamic (to be implemented with DB-query). Static list of values should not be captured in the service descriptions itself (for reasons of maintainability) but in a separate document.

Transformations typically are captured using a two-column-format, one column describing the "query" (just one source attribute, or multiple attributes with some operations), the other the target attribute.

The validations to specify concern checks that are not considered to be part of the pre-conditions.

Metrics can have the following sub-attributes:

• average calls/per time unit
• peak volumes
• max response time

A service can call one or more other services, each having their own message format in and out and transformations involved in that, which then also needs to be specified.

Specific Attributes

In case of Data Services also the following attributes can be applicable:

• data source (name of the database, or other)
• a (restricted) data model
• key attributes
• (logical) query, insert or update statement

Application and Batch Services typically also can have the following attribute:

• algorithm

Process Services also have a process orchestration that is described using an activity diagram (preferable using the BMPN notation) or a sequence diagram. Process Services often have a human interaction being involved.

Generic Supplemental Requirements

In case of asynchronous services you are likely to have a need for an "error hospital". Preferably you have some generic mechanism for that. For each individual service you then only need to specify how long and with what frequency a retry needs to be done, before it will end up in the error hospital. The requirements for the error hospital itself will be generic, describing how a systems or application administrator can cancel or retry the service (when possible).

Other generic supplemental requirements might concern:

• audit requirements
• logging
• security

Per service you only specify how the generic mechanisms apply.

Oracle BPM Enterprise 10gR3 for WebLogic on XP

Officially Oracle BPM Enterprise 10gR3 is not supported on Windows XP. When you try to install it using the default path, you probably will experience some exceptions like a ClassDefNotFound or an IllegalStateException. So what to do when you're bound to XP but want to juggle with BPM Enterprise nevertheless? This is how I did it. But remember it's not supported, so don't start complaining when it does not work for you.

What I did was to run the installer up to the point where it asks you to start the configuration wizard, and then quit. The configuration wizard offers the option to install a WebLogic Server (WLS) for you. However, I created a WLS domain myself, with only an admin server and no managed server, and called it OBPM (but you can call it DonaldDuck or whatever you like). Once successfully created, I started the server.

The OPBM Enterprise configuration wizard has an option that let's you choose to change an existing WLS domain rather than to create a new one, to deploy the process engine and web applications on. So I chose my OBPM domain.

The ClassDefNotFound error I prevented by not choosing to install the Oracle BPM transport provider. You can install it later, and perhaps when you concentrate on that, the ClassDefNotFound error can be tackled as well. I did not yet get that far. I explicitly configured the tablespaces of the engine and directory schema's, but had to key in the names in upper case (e.g. in my case USERS and TEMP, instead of users and temp), otherwise the installation of the schema's failed telling me that the tablespaces did not exist. Weird.

Anyway, using the installation path as I described above, resulted in a flawless installation on my XP Professional

Need to know more? Check out the Oracle BPM 10.3 Configuration Guide.

Dynamically Switching Rules Dictionary Versions

Suppose that you are using Oracle Business Rules in a Java application. And suppose you want to be able to change and test your rule set without bothering other people. Wouldn't it be nice to be able to work in a copy of a dictionary and activate that only for your user session? This can be achieved as follows.

I assume one dictionary of which there can be multiple versions. Of course the same principle can be applied to multiple dictionaries.

First implement some mechanism for storing the default version of the dictionary, and that will be retrieved every time before calling the rules repository. I use a properties file for that, because you can change a properties file dynamically. Then have some page from which the user can pick an available version from a list. Once a version has been chosen that differs from the default, that will be the version used for that user session.

Now how to get the versions of a dictionary from a repository? That can be done using the following Java code snippet, which is based on a WebDAV repository:


// repositoryURL is a String containing the URL to your repository
// rulesDictionaryName is a String containing the name of the dictionary

RepositoryType repositoryType =
RepositoryManager.getRegisteredRepositoryType("oracle.rules.sdk.store.webdav");
RuleRepository rulesRepository =
RepositoryManager.createRuleRepositoryInstance(repositoryType);
RepositoryContext repositoryContext = new RepositoryContext();
repositoryContext.setProperty("oracle.rules.sdk.store.webdav.url", repositoryURL);
rulesRepository.init(repositoryContext);

dictionaryVersions = rulesRepository.getMarkerNames(rulesDictionaryName);
for (int i=0; i < dictionaryVersions.size(); i++)
{
dictionaryVersions.set(i, ((String)dictionaryVersions.get(i)));
}


When the test was satisfactory, the chosen version can be stored in the properties file, making the default for every new user session.

Moving a WLS Domain

The following describes how to move your own sandbox kind of WebLogic Server domain. This method is not supported and should not be used to move any other kind of domain. It is also not guaranteed that any applications deployed on it, will move flawlessly with it. And it I tried it only on Windows.

So why describe it anyway? Well, just like me, you might have not payed attention when creating a domain and it therefore may have ended up in your product home directory. And you might, just like me, be too lazy to want to run the wizard and create a new one. Not that it is so much more work to do so. Finally, just like me you might be interested to know where WLS stores this kind of information.

Moving a domain can be done as follows:

• Copy the domain directory and everything under it, to the location where you want it to be
• Search all the files in the domain directory for the fully qualified path name where the domain was located (e.g. d:\oracle\product\bea\domains\MyDomain, and replace that by the fully qualified path name where you want the domain to be (e.g. d:\wls\domains\MyDomain). You will find a couple of files, among them .cmd files.
  
• Find the nodemanager.domains file (in my case in the d:\oracle\product\bea\wlserver_10.3\common\nodemanager\ folder). Find your domain in there and modify that manually (e.g. to d\:\\wls\\domains\\MyDomain)
• Finally, change the short-cuts to start and stop your domain to point to the correct locations.
  

That did it for me!

To BPA or to BPM, that's the question

The other day I heard Thomas Kurian talking about the future of the Oracle technology stack. Among other things, he mentioned the Oracle BPA Suite and the Oracle BPM Suite (fka BEA AquaLogic BPM). According to Thomas, the "structured" BPA Suite aims at rigorous process modeling and simulation, where the "agile" BPM Suite aims at iterative process modeling.

Methodological me tended to hear that he was saying that the BPA Suite was more suited for plan-based development, where the BPM Suite would better support agile development. Knowing both of these tools, I found that a somewhat rigorous statement by itself, so I dug into the subject somewhat more.

Yes, the Oracle BPA Suite has a huge amount of modelers and an astronomical amount of symbols. And yes, being able to use the tool to its full extend requires a learning curve that looks the inverse of the stock markets of these days. But does that mean you cannot use it in an agile way? Not really, because being agile is less about how long it takes to learn something, but more about being able to apply it to create new or change existing software.

On the other hand, would the Oracle BPM Suite not be suitable for rigorous process modeling and simulation? Again I don't see why. You could easily have a very rigorous way of developing systems with strict procedures to follow, including an extensive QA process and still use a tool like the BPM suite.

Maybe we need to have a look at the subject from a different angle. Let's start with a limited feature comparison. Limited in that I restrict it to a development environment based upon a SOA with a focus on the high level topics of the models that are supported, how Governance can be enforced, and the type of systems that you can build.


Models and Governance

In a nutshell, with the BPA Suite you can start by defining business processes from a high-level context diagram up to a detailed design. At the higher levels you can use Value (Added) Chain Diagrams, or VACD's for short, that at a specific point map on BPMN diagrams. Those BPMN diagrams can then be transformed into a BPEL design, which finally can be implemented using JDeveloper. The higher-level modeling can be done by Business Analysts while the detailed BPMN model typically will be done by someone with a developers background.

With the BPA Suite you can define roles and restrict access to specific modelers of the tool. This allows you to implement a rigorous Governance model you might have, where the responsibilities for the different roles are well supported by the tooling.

With the BPM Suite you can define processes using BPMN (or similar notation, each being just another view on the same source). Next to that three different "profiles" are supported: Business Analyst, Business Architect, and Developer. The only difference being that a Business Analysts sees the least and a Developer the most details of the same process.

Unless you start doing really fancy things, the BPM Suite does not support a rigorous Governance model as far as responsibilities are concerned, as nothing prevents a Business Analyst from changing his profile to developer to see what has been coded under the hood and even change that.

So the BPA Suite supports a rigorous enforcement of Governance and capturing of requirements, where the Suite BPM supports that hardly if at all. But as such I don't want to call that an "agile" aspect of the BPM Suite.

Regarding Governance, there is one other significant difference. The BPA Suite itself does not result in an executable model. BPMN can be transformed to BPEL, but that is only a blueprint. After sharing the blueprint with development (as it called), a developer picks up the BPEL blueprint and implements it.

The BPM Suite leverages XPDL which provides a means to draw business process models, but also is an executable model. So for the BPA Suite you could say there is a strict hand-over from design to implementation, where with the BPM Suite there is no such thing.


Type of Systems

Currently the BPM Suite clearly is coupled to BPEL. In our practice BPEL is heavily used to integrate systems, with little to no human workflow involved. But that does not mean that you cannot use it for processes that almost completely involve human interaction, and in practice it probably will.

Although at first sight the BPM Suite primarily seems to target processes that involve human interaction, nothing will keep you from developing processes that are fully automated. BPM processes can be deployed as services with a WSDL interface, and call other services, allowing it to be used for service orchestration only.

My conclusion is that regarding the type of system you can build, there is not really a significant difference between the two. Although with the BPM Suite it is much easier to create a user interface than with the BPEL human workflow. But are processes with a lot of human interaction agile and processes that are not rigorous?


Conclusion

When talking about rigorous versus agile and iterative, the significant difference I see is that with BPM it is hard if not impossible to build a solid wall between analysts and developers. And yes, it is true that agile development methodologies do promote breaking down that wall wherever possible.

By the way did I already say sorry for the lack of pictures this time? No? Sorry!

AIA & Canonicals, Just Good Friends?

Last time I talked about the Canonical Data Model (CDM) pattern. What I haven't discussed yet, is how this pattern is implemented in the Oracle SOA Suite.

Actually the SOA Suite itself does not explicitly support this pattern, simply because enforcing any specific data model should not be seen as the task of any infrastructure tooling, including the SOA Suite. Nevertheless, the concept of a common data model can very well be implemented for specific industries. The goal being that parties in that industry can communicate more easily because by using a CDM they actually talk a common language, at least to some extend.

This concept already is being used in various "industries". Examples are CDM's for governments allowing central and local governments to exchange information with each other about their citizens. CDM's in the health care industry allow doctors, insurance companies and other stakeholders to exchange information about patients.

More recently, Oracle introduced the Application Implementation Architecture or AIA for short. As in the communication about it the focus seems to be on the common process aspect perhaps a little bit of a hidden feature of AIA, but the industry foundation packs of AIA could not exist without the CMD's they are based upon. Perhaps the common data model is of even greater value than the common process.

Once defined a CDM should be accessible by every process that is making use of it, preferably by means of XML schemas. In case of the SOA Suite, rather than importing (and with that copying) the schemas in each and every BPEL project, a way to do this is by including all coherent XML schemas of a CDM in one single, dummy BPEL process, as explained by Marc Kelderman.

The Case for Canonicals

You might have heard people talking about a "Canonical Data Model" or CDM for short. You might have even heard the rumour that having a CDM is critical success factor in achieving the true benefits of a Service Oriented Architecture. But in the meantime you still have to encounter the first situation in which it actually is being used. Is a CDM really a must-have or just another buzzword?

First let me try to explain what a CDM actually is, apart from just being one of the integration design patterns. In short you could say that a canonical data model provides a generic view on the structure of data that systems deal with, like for example a generic concept of what a Customer is, what attributes it should have and the data types and formats of those attributes are.

It might surprise you that having a common view of an entity like "Customer" often is far from common practice. Imagine a big organization like a bank having many systems with different purposes, because of merges often from different companies. Such an organization can easily have as many definitions in their data dictionary of "Customer" as they have systems that deal with customers.

Now what if such an organization needs to integrate all these systems with SOA using XLM transformations for that? If there are N systems to integrate, than in principle there are N * (N - 1) mappings possible for each type of Customer. In case of 4 systems that need to exchange customer data, that already means 12 mappings, as you can see in the following picture. But if you define one generic definition and map to and from that definition, than the maximum number of mappings are 2 * N. In case of 4 systems that means only 8.


A larger bank easily has hundreds of applications with dozens of different definitions of "Customer", let's say 30. Then the difference is 870 versus 60! And that is only for Customer, and there are plenty of other entity types that needs to be exchanged as well, like Account, Address, etc. You get the picture?


So the incentive to use the Canonical Data Model design pattern, is to reduce the number of mappings and with that the inter-dependency between systems, the complexity of the overall integration and, last but not least, the maintenance of all that. For larger organizations this can make a huge difference.

Having said all this, it probably never is the case that all systems need to integrate to each other, let alone that this all the time requires a two-way mapping of every entity involved. To know if an entity should have a definition in a CDM, it depends in how many mappings it will be involved in. When there are more than three systems that all need to exchange an entity in a bi-directional way, than a canonical definition of the entity starts to make sense.

The case against canonicals is that in some organizations it might prove to be far from trivial to get a common view of how the generic definition of a specific entity should look like.

About Business Processes, Use Cases & SOA (4 & End)

This posting is a follow-up on a previous posting in which I explained what artifacts might be appropriate in case of creating an analysis model out of a set of system use cases for a SOA project.

In this third and last posting, I will show how the (platform independent) analysis model can be transformed into a (platform specific) design that leverages BPEL.


Design

The design involves mapping the analysis to artifacts that actually are implemented. Assuming that the Technical Architecture dictates a Service Oriented Architecture that uses BPEL to implement services and service orchestration, the design would at least include the following:

• WSDL’s
• A diagram design of the BPEL processes to implement
• A database design (that supports retrieval of resident information and storage and retrieval of parking permits and their applications)

An example of an XSD already has been provided. Including WSDL’s in this case would not add much value, and a database design is too obvious. A design of the BPEL process to implement, in this case sufficiently has been provided by the activity diagrams already created. This probably will often be the case.

To show how the implementation might look like the following two BPEL process diagrams are included.
A part of the ParkingPermitProcess looks as follows:

Not surprisingly the initial business process diagram and the implementing BPEL process flow look very similar.

The same holds true for the user goal level Validate Parking Permit use case that looks as in the following picture (that actually zooms in on the ValidateParkingPermitApplication step of the previous picture):

In practice, you can imagine a human workflow step to be included that supports manual intervention of the outcome by Parking Services.

This ends a short history about the road you could walk from business process modeling to a BPEL implementation, and that with use cases as well. Now was that impressive or what?!

About Business Processes, Use Cases & SOA (3)

This posting is a follow-up on a previous posting in which I explained business process models can be drilled down to user-goal level use cases and how to do service discovery based upon process models.

In this third posting, I will show how the requirements that have been captured so far, can be transformed into an analysis model that will provide the base to build the design on.

Analysis

What kind of artifacts should be created during the Analysis process depends on the nature of the use cases and the architecture that is going to be used to implement them. The most apparent candidates for adding detail are activity or sequence diagrams, class diagrams and (where useful) collaboration diagrams (used to describe how various “components” work together). For SOA projects also message descriptions and message transformations are obvious candidates.

For services that support more than one operation you also need to specify the names of each individual operation, as well as the types of their iand output messages.

Depending on its granularity, a service supports a summary use case (like the Parking Permit process), a user goal use case (like Apply for Parking Permit) or a subfunction use case. No example of the latter has been included, but you can imagine that for each separate channel (letter, email, SMS) a subfunction use case could be created that describes a generic notification services that can be used to send all kind of notifications to third parties.

Unless parallel development is be done where other (parts of the) system(s) depend on a service to be build, at this point there is not much value in specifying the exact WSDL of the service. For any external service you use, you need to have at least the WSDL location if not the WSDL itself.

Activity Diagrams

When there is a flow involved, it might be useful to create an activity diagram. An obvious example would be a use case for a service that will be implemented as a BPEL process. As already noted, the activity diagram for the Validate Parking Application is an example of that. But use cases that involve a user interface with a complex screen flow, also are good candidates.

Class Diagrams

When there is data involved, a class diagram seems to be the obvious choice to document that. Many people doing SOA projects never seem to make a class diagram. Realize though that class diagrams add as much value to SOA projects as they for example do to pure Java/XML projects, as messages are about handling data as well. Having class diagrams available can add great value to optimizing the process of defining message formats and transformations.

When analyzing the Parking Permit use case the following classes can be recognized: Resident, Parking Permit Application, and Parking Permit. A distinction has been made between Parking Permit Application and Parking Permit, as not all applications will result in a permit, and the application follows a process with statuses that do not apply to the permit itself and vise verse.

Not very explicit in the description but obviously needed if you think about it, is a notion of an Area. You will need this in the process of determining if there are sufficient parking lots available. You might argue that the reason for not having discovered this earlier is because the way the waiting list is being processed has not been worked out to the proper level of detail.

The class diagram for the Parking Permit use case could look as in the following figure:

Message Descriptions

What format to use for a message descriptions probably foremost depends on who needs to validate it. Some people will prefer more “logical” descriptions in Word, while more technical oriented people probably have no problems with XSD’s.

Mind that to be able to create XSD’s that translate 1:1 to an implementation, it is important to understand the technique of implementing messaging. For example, initially one XSD has been created for the Resident and one for the Parking Permit Application, only to discover that it was more practical to create one XSD containing both and use that as the format for the message going from the resident to the Parking Process service. If you pay more attention to detailing the Apply for ParkingPermit use case, you probably would find that out up front.

For the sake of example the response message has been kept simple by returning a string stating that the application has been received successfully. The description of the request message looks as follows:

Other message descriptions that need to be made are the request and response messages for the Verify Ownership, Verify Electoral Registers and Verify Residence use cases.
You should keep the message descriptions separate from the use case descriptions, to support reuse. Refer to them from the use case descriptions instead.

Message Transformations

How message are transformed from one format to the other depends on the situation. For example, in case of BPEL, transformations can be done by doing one or more assign operations or by using an XSLT transformation, which in both cases may involve complex XPath queries or regular expressions.

For this reason transformations probably are best described in text, as has been done in the following example:

The example is trivial in that transformation consists of using a subset of the fields of the source and mapping those 1:1 on fields of the target message.

You can image than in practice often more complex transformations need to be done, for example in case of n:m mappings. In practice using a two-column format often suffices, where the (left) Source/Transformation column specifies which source fields are involved and any logic that needs to be applied to that, and where the (right) Target column specifies what the (single) target field is.

As with message formats you should keep the message transformations separate from the use case descriptions to support reuse.

Where to Stop

Once the analysis model has been worked out to a sufficient level of detail, you are ready for the design. What “sufficient” means in this context, depends on many factors, the most important ones being the following:

Nature of Engagement

In some cases a formal process needs to be followed that requires every change of the specifications to be approved up-front. On the other side of the spectrum there is the agile approach by which part of the (detailed) requirements are captured while validating iterations of a working program.

Skills and Habits of Developers

Developers are most comfortable with what they are used used to working with. However, you should be aware that when every developer involved needs to get used to one broadly accepted way of creating specifications almost always outclasses the situation in which developers need to get used to as many different styles as there are other developers. Not to mention the effort that needs to be put into the validation process involved with that.

For most projects that involve requirements analysis, class models are very useful to developers, even in the case of BPEL development.

Application and Technical Architecture

The development of data-oriented systems that depend on a well-structured database can highly benefit from creating a detailed class diagram. In case of use cases that involve a user interface, activity diagrams normally only add value when there is a complex dialog involved.

For SOA projects that primarily deal with messaging it probably suffices to detail classes to the level that all attributes and their types are known. Message formats and transformations often need to be worked out in detail. In general, activity or sequence diagrams add great value to business processes and services, as they support a more effective implementation.

Other architectures, for example identity management/security, on their turn require yet other details.

A final remark that needs to be made at this point is that use case analysis should not be confused for a technical design. Although some people state that class models, and activity diagrams that describe system-internal behavior, are “technical” they actually only capture detailed requirements or validate higher-level requirements from a different angle.

To be continued ....

About Business Processes, Use Cases & SOA (2)

This posting is a follow-up on a previous posting in which I explained how business process models and use cases can be used to capture requirements. It especially highlighted how use cases can be used for aspects that might not that easily be captured using business processes alone.

In this second posting, I will give an example how the business process model of the previous example is drilled down to ensure that all nodes in that model are of the level of user-goals, and what the benefit of that is. I will also discuss a way to discover services from the business process model.


Drilling Down Business Process Models

When looking at the business process of the previous posting, you might notice that each activity actually is a use case of its own, most of them being at the level of user-goal use cases (which is a use case for which the user can execute it in one session and walk away happily after that). The only exception might be the Validate Parking Permit use case, that for that reason has been drilled down further to investigate if this really is at a level of a user-goal.

The result is the following Validate Parking Permit Application business process model:



As illustrated in this model, a couple of other organizations are involved in the validation, possibly making it a lengthy process, and initially suggesting that the upper level activity indeed is not a user goal level use case. But what if the other organizations have automated services available that respond within seconds? What this shows is that the level of a use case in some cases depends on the options for implementing it. This certainly is true in case of a Service Oriented Architecture.

For the following it will be assumed that such services do exist, making the Validate Parking Permit Application activity indeed an activity at the level of user-goal use cases. In the context of the Oracle Unified Method this automatically classifies the diagram above part of the use case details rather than a business process.

However, the question if it is a business process model or just use case details, is just an academic one. What is important is that you have a clear idea of when a business process needs to be further detailed. It is advisable to drill them down to the level of user-goals, for the following reasons:

• User goals provide the most effective level to start from and create system use cases from business use cases to describe what the system should do (*). For example, it is at the level of user-goal business use cases that you will decide whether a goal will be kept manual or supported by a system.
• You typically either implement a user-goal level use case or you do not implement it at all, making it the optimal unit to estimate and trace requirements from there.
  

(*) Business use cases have the business as subject and are written by business analysts to document business processes. System use cases have the system as subject and are written by system developers to document how actors communicate with the system to achieve their goals.


Service Discovery

Assuming that the requirements so far point to a solution using a Service Oriented Architecture, it is imperative to discover the services in the requirements. This is not only important for creating the application architecture but also provides important input to the estimating process.

One of the reasons to do business process modeling in the first place is that it relates very well to a Service Oriented Architecture, which makes implementation of the business process itself possible. You can imagine that the Parking Permit process is implemented as a longer running process that may take weeks to complete. But that will not be the only service involved, as the Parking Permit process itself needs other services to complete.

There are several approaches to discover services. One of them being by reviewing a business process and identify where the transitions are from an activity of one actor (swimlane) to that of another. In general this indicates a candidate service. In the example the candidate services are in the activities:

• Apply for Parking Permit
• Notify Resident of Waiting List
• Notify Parking Service of decision
• Notify Resident Permit Ready for Collection
• Collect Parking Permit
• Verify Vehicle Ownership
• Verify Electoral Register
• Verify Residence
  

The Apply for Parking Permit candidate service obviously is the starting point for the Parking Permit process itself. You can imagine that the web site of the municipality provides some form that the resident can fill out and on submit calls the Parking Permit process.

The Notify Resident of Rejection, Notify Resident of Waiting List and Notify Resident Permit Ready for Collection (from Parking Services to the Resident) are candidate services whereby the Parking Service process needs to call out some provider that handles multi-channel notifications to third parties. Whether this will be one service that can handle some generic notification, or three different services that each handle a specific notification type, or any other combination, is a design decision and at this stage is yet to be determined. Mind you, we are analyzing the business and capturing requirements, not yet defining the solution!

The Notify Parking Services of Decision points to yet another candidate service that the Resident can call to get the application removed from the waiting list.

The Verify Vehicle Ownership, Verify Electoral Register and Verify Residence already have been indicated as existing services. However, if they were not, creating them would have been outside the scope of the Parking Permit process, as those services would then have to be created by third parties not involved in the project.

From the last example above, we can conclude that transitions to activities within the scope of secondary actors that are not within the scope of the project, only indicate calls to external services.


Prototyping the User Interface

Any use case that has a user interface associated with it, might be detailed with a conceptual screen layout. Note that a conceptual screen layout is not a design, as it does not specify an actual screen layout, let alone aspects like styling. It’s main purpose is to specify which data should be shown, and should be validated during the review.

Depending on if and when you start creating a Domain Model to identify the business entities involved, conceptual prototypes provide input to or can be use to validate that model.

For example the use case Apply For Parking Permit could be detailed with a screen layout as follows:


Other use cases that may require some conceptual layout are the following:

• Notify Resident of Rejection (mail/email/SMS)
• Notify Resident of Waiting List (mail/email/SMS)
• Notify Parking Services of Decision (mail, screen)
• Notify Resident Permit Ready for Collection (mail/email/SMS)

When analyzing the Validate Parking Permit Application use case, you may find that Parking Services wants to be able to override the decision that comes out of the verification, for example by blocking a parking permit for someone that appears to hire a garage box (which none of the external organizations would note). In that case that use case also would require a conceptual screen layout.


To be continued ....

About Business Processes, Use Cases & SOA (1)

It is my observation that since the introduction of SOA (Service Oriented Architecture) many developers are kind of lost when it comes to capturing requirements and doing design. Quite a few people already got lost during the "giant leap" from relational to object-oriented analysis and design, and (around the same time) had to jump from waterfall to iterative, and more recently from plan-based to agile project approaches. But since SOA too many people have no clue whatsoever how to properly write down customer requirements instead of producing designs of some services (if they even understand the difference).

Apparently some of us are convinced that "legacy" methods like the Unified Process do not properly address the issue of services. What I sometimes hear (and I don't exaggerate) is that a service delivers some reusable piece of functionality that cannot be pinpointed to a specific use case, so use case are useless. The best they can deliver is some flow diagram representing an orchestration of some services and call that a "business process".

Even when I was still clueless about SOA, I already found that hard to believe. What has become so different about user requirements since there is SOA that we cannot capture them as we used to? Has SOA really changed the way we think about requirements similar to how the Star Trek transporter will redefine the concept of transportation in a future near us? Does this question sounds rhetorical to you?

With this article and a couple yet to come, I hope to shed some light on this matter and help you to become aware that the world still turns and it is not you who is spinning around. As an example of this I will try to explain a way (not the but a way) of how you can capture requirements in a business process, and from there go to use case descriptions and finally implement services based on that.

As you might expect from me I will present this in the context of Oracle Unified Method (OUM), but don't let that scare you off. The targeted development environment will be BPEL.


The Case

The case I will use is of moderate complexity. The following activity diagram documents a business process concerning the application of a parking permit by a resident of some municipality.

At this point it is important to point out that this is a true "business process", as it only concerns business level actors like people, or organization units, and totally abstracts from any system supporting it. At this point the whole process could be manual, for all you know.

I find that important to point out as too often I have seen the situation in which the "analysis" is limited to a description of how some system is going to be implemented rather than on capturing requirements. You should only skip that latter step when you do it consciously and the risk of missing something that proves to be important later on is relatively small.

What might surprise you, is that the same business flow can be documented as a use case description, typically of the scope "enterprise" (that is cross organization-unit). In this case it also concerns a business use case, as it describes how the resident communicates with Parking Services, which in this context is an organization, rather than how this resident communicates with some system.


The Use Case

Presented as a use case the same business process could look as follows:


Normally a use case will not be created in one blow at this level of detail. It is more likely to be created in a few iterations of which the first one might suffice to document only the stakeholders, goal and main success scenario together with some business rules. In OUM this is what the Business Requirements process is supposed to be limited to. The example use case has been worked out to a greater level of detail, which would typically be done in the Requirements Analysis process.


How Use Cases Add Value

Compared for example with the situation where only a business process diagram is available, adding use cases adds value in that a (detailed) use case description provides the opportunity to specify aspects of the business process that goes beyond that of what you can express with only a diagram.

One of those aspects is stakeholders that are not directly involved in the process. In some cases identifying such stakeholders might give reason to extend the scope of the use case, like identifying the stakeholder Neighbor might have lead to considering to include in the business process a step that notifies them as well.

Other aspects that the diagram does not cover are the goals, the triggers, preconditions, and postconditions of the use case. All of them helping to validate the use case and some of them providing useful input for the next step in which the use case is going to be analyzed.

An advantage of putting it down in writing that may not be so clear at first sight is that by forcing yourself to express the business process in words might help you to discover flaws and omissions in the original process.

The value of putting effort in converting a business process into a use case description is not always easy to determine. It depends on many factors like the ability of people reviewing the business process to identify flaws in it, or how easy it is to correct errors later in the process. Probably the best advice would be: when in doubt, don’t hesitate and just do it. In case of the example the business process has been converted into a use case description in less than half an hour. The total process took much more time, but that was because the business process model needed to be corrected, because of errors found while describing the use case.


To be continued ...

No Country for Old Men

With the risk of giving you the impression that I go to the cinema every week, I want to tell you about the movie I saw this Saturday. Still not the Kite Runner, as I went with my wife and she already saw that one. Instead I saw No Country for Old Men.

It is dangerous to compare it with anything else, but if I have to I would compare it to a gloomy version of Pulp Fiction. However, that resemblance is limited to the level of violence being used combined with a peculiar sense of humor. There the resembles stops as quick as it started.

Perhaps it is my lack of imagination but there was only one scene that I found to be predictable. For the rest of it I had no clue where it was going, and that pleasant feeling lasted until the end. I can't mention any character that was not convincing, including the side-kicks. Come to think of it, except for the hunter and the hunted every other character made a pretty "normal" impression. That is, as far as people from Kansas can be considered to be normal (no offense meant).

On a scale of "worthless" to "genius", I gladly give it an "excellent".

Cloverfield

Yesterday I went to the movies as a kind of birthday present with a nephew of mine who recently came of age (being 18 in his case). Offered the options to either go to The Kite Runner or Cloverfield, for some reason he choose the latter. Now why would that be?

Pehaps the best way to describe Cloverfield is as a crossover between The Blair Witch Project and Godzilla, inheriting the better aspects of both of them. The whole movie is shot with a hand-held camera. Somewhat disturbing in the beginning but I got used to it pretty soon. Bending your head to the left or right on a regular base is a good exercise anyway.

It already has been described as an exponent of the YouTube generation, and some critics state that it redefines the concept of monster movies. Only time can tell if they are right. What I can tell you now, though, is that you don't need to be afraid of too much character building (there is none in any significant way), and in a pleasent way the monster is more a sidekick than the main dish of the story.

If you already saw the Kite Runner, you might consider Cloverfield as your next target. It's worth that big screen.

Name-value Pair Transformation in BPEL

A pattern you often see is that some generic message type containing a number of 1..n name-value pair attributes needs to be transformed to specific attributes of a specific message type. For example, a portal of a some local government accepts a range of service requests that need to be transformed to a specific request for a passport, a parking permit and so on, to be able to be processed by specialized back-office systems.

The generic message type could for example be defined in an ServiceRequestForm.xsd as follows:


As you can see, the name-value pair attributes are passed on a a repeating set of formItems.

Let's assume that the specific type of message it needs to be transformed to, is based on the value of the serviceType attribute. In case the value of that attribute is "passport request" the ServiceRequestForm needs to be transformed to a PassportRequest.xsd consisting of the following attributes:


Now let's assume we are using BPEL to process the messages and let's assume no performance reason is keeping us from using an (XSLT) transformation (Transform) instead of a series of copy actions in an Assign. So for passports we create a transformToPassportRequest.xsl in which we would like to map the formItems at the left side of the following picture to the specific name, address and city attributes at the right side.


The simplest way to achieve this is by creating a so-called user-defined XSLT template that takes the name of an attribute as argument and transform the corresponding generic name-value pair attribute to the specific attribute. To this purpose we put a template called "getItemValue" at the bottom of the XSL file, as follows:


After you have done so, you will will find the getItemValue template in the User Defined Named Template drop-down in the component pallet of the XSL editor.


After you dragged & dropped that template from the component pallet in the middle section of the mapper, you can create a link from the formItem attribute to the template and from the specific attribute to the template, as has been done for the address attribute in the following figure:


To make that the template transforms any formItem attribute for which its name attribute has the value "address" you need to pass in 'address' as argument.


In a similar way you can transform formItem to the two remaining attributes, finally resulting in something like the following:


Ah... if everything would be as simple at this!

Where To Download OUM

Edited on August 2, 2011 with the correct link and partner types.

As a follow-up on my previous post about the Oralce Unified Methodology (OUM) being out, you can download the method from here.

Mind that OUM is only available to Gold, Platinum and Diamond Partners. On the download page is an email address that can be used to ask for a password that you will need to be able to unzip the OUM download file.

There is a known "bug" with OUM, being that if a Word work product is exchanged between two people that have not installed OUM at the same location (by default C:\method), the person receiving the template will get an error when trying to open the document, saying that the template (.dot file) cannot be found. The solution is to make sure that everyone installs OUM at the default location and by letting people that have not done so, uninstall and then reinstall it at the default location.

OUM Is For Weenies, Real Developers Create Their Own Method!

When I encounter a situation where people could greatly benefit from a methodology to structure their development process, and suggest to have a look at Oracle Unified Method (OUM), I often get as a reaction that OUM is too big and too complex.

Funny thing is that I hear this often being said by people that some years ago took months if not years to learn methods like the Oracle's Custom Development Method (CDM) and Project Management Method (PJM). Sometimes it is even said by people that never had a look at OUM themselves and only judge based on hear-saying.

But what would be hilarious would it not waste so much resources is that, rather than pick a method of the shelf, people start working on some method of their own. It usually starts small, initiated by an imperative need to write down a specific procedure and capture some standards & guidelines etc. But from there the library grows and before you know it they have spend man-months on defining their own method, spending a multiple of the budget it would have taken to adapt OUM, including a customization to the organization specific needs.

Therefore guys, before you start inventing your own wheel, have a look at OUM and check if that can make you start rolling.