At the end of this month on Jan 30th, I'm heading out to San Francisco for a new conference The Open Group is launching - the IT Specialist Conference. It will be held on the last day of the The 17th Enterprise Architecture Practitioners Conference which runs January 28-30. Both are at the Fairmont Hotel, San Francisco. If you plan to be out there and would like to meet for a chat please respond to this blog. I'll be speaking on a panel and doing some podcasting from out there.

This week I spoke with James de Raeve, VP of Certification for The Open Group. The Open Group is kicking off its IT Specialist Certification program to attendees at the conference along with current Open Group members. We talked about the role of the IT Specialist, and the new certification program.

You can listen to the Podcast here:

Listen to the entire podcast Download file

You can also read the transcript of the podcast.

Posted by bethgb in Industry News • Podcast • SOA Design | Permalink | Comments (0) | TrackBacks (0)

James Taylor recently blogged on Decision Service Design and linked to the session in SOA in Action Brenda Michelson and I did together on Business Driven Service Design. In his post James writes:

"It is pretty clear to me, having listened to their overview, that what I call a Decision Service is a subset of what they refer to as Business Function Services. Decision Services might be considered a pattern for Function Services in their approach. Decision Services typically are stateless, short-lived and used synchronously by other services. They take data in, might request additional data and then return information about a decision. They don't update databases, they don't take action, they just make decisions."

In another post James defines a Decision Service as: "A self-contained, callable service with a view of all the conditions and actions that need to be considered to make an operational business decision... Or, more simply ... A service that answers a business question for other services."

Using this definition, James is absolutely correct. A Decision Service is indeed a subtype of a functional service. As we build the method out the intention is to continue to identify and model different service patterns which can be used as templates for creating new services. These service models can reduce time, effort, error, cost, and risk, therefore having the potential to be extremely valuable. What Brenda and I are focusing on is a way to consistently model different types of services so the patterns are reusable.

So the essential question is, how do we model a Decision Service in a manner that is consistent, and sufficiently explicit to enable consistency and reduce risk in implementation? James picked up on the characteristics we defined to help us sort it out, characterizing a Decision Service as: "stateless, short-lived and used synchronously by other services." However, I think it is likely that this is just one type of Decision Service. I would call it a synchronous Decision Service, to be used when an instant answer is required and processing is necessarily blocked until the answer is given. However, there might also be Asynchronous Decision Services. In the post where James defines the characteristics Decision Services must conform to, one of the characteristics is:

"Manages exceptions well. Not only should it respond sensibly when it cannot decide, it should ensure that enough context is returned as to why it could not decide to assist a manual process."

I would characterize this type of service, which involves waiting for human interaction, as an asynchronous, long-lived Decision Service. This is a very different model than the above described Synchronous Decision Service. Perhaps there are others as well.

The real value of Business Driven Service Design is that it provides guidelines and best practices for modeling different types of services. Once we have a common way of communicating service specifications as explicit models any type of service can be designed in a consistent, reusable manner. Over time the community will define and share service models if they find the models speed implementation while reducing risk. That is one of our goals.

James asked about modeling information needed to make a decision. Each business service represents a business activity. The model includes all the business policies, actions, and information needed to perform the business activity. In this case the activity is making a decision. If you can determine specific types of information, policies, rules etc that comprise a type of Decision Service, then you can create a reusable template that will save implementation time and cost.

Does this make sense?

Posted by bethgb in Business Intelligence • SOA • SOA Design | Permalink | Comments (0) | TrackBacks (0)

Last week Brenda Michelson and I did a presentation in the SOA in Action virtual conference on Business Driven Service Design. This presentation is a sprint through about 2 days worth of material. It's something Brenda and I have been working on for over a year now, and starting talking about over 10 years ago.

The goal of the method is to design services using a business-driven top-down approach starting with events, processes, or interactions - depending upon the business scenario. Ultimately all of these resolve to business activities, which are decomposed into different types and levels of services. It is a method that enables an incremental approach to building a strategic agile architecture. We're pretty excited about it, and are looking for feedback.

Please take a few moments to answer a short survey. As a token of our appreciation, ALL respondents will receive a free copy of the SOA Illumination Service Meta Model. The meta model contains the constructs and relationships required for proper service design, repository layout, consumer-provider agreement establishment and operational instrumentation.

In case you missed it, the webcast is available for replay, as are all the sessions in SOA in Action.

Posted by bethgb in SOA Design | Permalink | Comments (0) | TrackBacks (0)

Recently I’ve been delving into the specs associated with Web services, including BMPN, WSDL, UDDI, ebXML Registry, and WS Policy. The focus of this research was to determine what information needs to be captured in the requirements and design phase to fully specify the Web service throughout the life cycle.

We had a few email exchanges with Miko Matsumura about policy metadata mainly to determine what type of information is necessary to collect policy requirements (which are part of the business requirements). But after a few go a rounds, and after looking at metadata specs for both ebXML policy and WS Policy, as well as this helpful comparison of the functional capabilities of different repositories (link courtesy of Miko) my conclusion was that what was really needed and sorely missing were templates for different types of policies so when analysts and developers are gathering requirements and designing services, they know what questions to ask and what information to document.

While all the relevant specs contain the information required to implement the service, none guide you in how to gather the requirements or create the optimal design. Our primary focus is on a process driven approach to right sizing Web services, but I am becoming more convinced of the need in the market for service patterns that can help developers identify different types of services that need to be implemented. These templates can then be implemented in UDDI (or the repository extensions based on UDDI) through tModels, which are technical models that represents reusable concepts. Examples of useful reusable templates which could be implemented in tModels include an implementation model for transactional services, or a data lookup service.

Identifying service patterns will help guide developers beginning SOA implementations to understand how to think about the types of services they need to implement. The types of patterns were looking at are types of service behavior (agents, monitors, stateful, stateless, long-lived, short-lived, transactional, etc.), service communication patterns (synchronous, asynchronous, request/reply, publish and subscribe, 1 to 1 messaging), and types of service policies (security policies, version control, SLAs, etc.). Once we have the reference models for each of the different types of services the models can be implemented a tModels and just configured for each service instead of created from scratch. This is somewhat of a cook book approach to SOA.

I’m asking here for a reality check here. Do you agree this would add value to SOA efforts? What do you think would be helpful and useful in helping analysts, architects, and developers evolve SOA within the organization?

Posted by bethgb in SOA Design | Permalink | Comments (2) | TrackBacks (2)

I spoke with Greg Carter, the CTO of Metastorm about their 2007 development roadmap for their BPM platform.

What interested me is their plans to provide extensions to their Stage Action Role (STAR™) modeling notation to include BPMN. Their plain is to continue to use their proprietary STAR modeling with business users to define the business processes and then use BPMN for modeling with IT. The underlying data will tie the different models together. The concept is that you can generate different views from the same design repository.

This concept maximizes flexibility, allowing different stakeholders to use the modeling techniques they are most familiar with. This is probably better than just saying to business people – get over it and learn to read BPMN models, or alternatively, saying to BPMN modelers “learn to walk business through the model in their own words”. I’ve seen good facilitators walk business people through E-R diagrams in a way that made it meaningful in them and allowed them to provide feedback. I still think it’s possible to do with BPMN. But more troubling is the shortcomings of BPMN. We simply don’t have one modeling technique that has the capability of expressing everything necessary for a business-driven approach to designing SOA systems.

The bad news is that Metastorm won’t have this functionality until the end of the year. I’m hoping to preview it sooner. But I'm happy to hear that tools vendors are working on the problem.

Posted by bethgb in SOA Design | Permalink | Comments (1)

In creating a method for designing Web services, we started with some assumptions going in.

#1 – the method had to be business driven. More of a top-down method than a bottom up method

#2 – the should provide derivable steps to create more predictable results

#3 – the method should provide some heuristics to evaluate correctness or quality of design

Modeling is really the best and least ambiguous way of creating a shared understanding of how the business works, because the model can then be functionally decomposed into processing requirements. Instead of interpreting business requirements, the model can help IT derive the system requirement from the business description. This will create less ambiguous communications between business and IT.

Brenda Michelson’s first stab at describing the business process was a typical story board. Our first discussion was whether, you can expect business to read models. While I do not expect business to start reading models off the bat, I know it is possible for IT to walk business people through a model. I have seen this work with data models. They may not have understood the models without a guided tour, but they were certainly able to verify the models with lots of narration.

We are now testing this hypothesis by using BPMN to actually tell the business story from a business point of view. The only problem is that BPMN does not depict human processes. A BIG, BIG omission. I wonder if that has to do with the political reality of BPMN’s genesis. BPMI, the organization first responsible for creating BPMN, shared a paid administrative director with WfMC. To honor their different areas of coverage, BPMI only focused on automated processes, whereas human based processes were the domain of the WfMC.

But this is akin to the issue of having one process engine to manage human workflow and another for automated processes. In reality, most end-to-end business processes are a combination of automated and manual processes. Many automated processes require human approval or handling exceptions. We are still running the machines – they are not running us (yet). Humans need to be involved. We need a unified modeling method that depicts both.

Brenda has come up with some very nice extensions to BPMN indicating human based events, gateways and activities. Just put a little stick figure human in there. It works for me. Hope we can get the OMG people to start listening to her.

In any case, I am pretty much convinced that IT and business alignment requires a formalized communication that enables developers to derive system requirements from business requirements without ambiguity or confusion.

Posted by bethgb in SOA Design | Permalink | Comments (1) | TrackBacks (0)

I’m currently working on a service design method with Brenda Michelson. Our goal is to take a pragmatic business driven approach to incremental (ie – project driven) SOA design and implementation. We plan to use standard modeling techniques and tools where ever feasible. The status of this project is that we have now defined the process and design artifacts, and our next task is to model out a case study and see if it holds water and to find the holes.

Our first question was how to define the process in the case study. Brenda’s first instinct was to story board. OK, she has one of those cool tablet computers where she can just draw stuff right on the computer. That might argue for me getting a new computer, but instead I argued that it was time for business and IT to start speaking the same language, and we should start off with BPMN right from the start.

To prove out this point I downloaded TIBCO’s Business Studio, which has the wonderful benefit of being free. This link is helpful, as the links from TIBCO’s home page all seem to be broken at the present time.

Eager to start modeling out our case study, I was a bit stymied at first. HOW do I even begin a project? Luckily TIBCO provided some tutorials, but unfortunately these links did not work either. The online documentation did help however.

Once I actually started modeling the process, the first problem I had was an BPMN problem. BPMN does not handle model human to computer interactions. We knew that going in, so I wanted to just define one of the “activities” as a sub-process which would actually be an interaction. But in TIBCO Business Studio while a sub-process can be “re-used” you can’t just click on a sub-process and further model it. I would need to go out of the process I’m working on, create a new process, model that, and then “re-use” it as a sub-process. Intuitively, I wanted a drill down capability, not just a pointer.

The next problem I encountered was in defining different types of events. BPMN defines 3 types of events: events that start a process, intermediate events, and events that terminate processes. TIBCO only defines start and end events. We are taking an event driven approach to design, and those intermediary events are important to our model.

BPMN itself defines a rich array to different types of events, including basic events, message events, timers, rules, exceptions, cancellations, compensation, links that link to a sibling process, multiple events – for example at the end of an activity several different types of messages must be sent. TIBCO’s tool does not support any of these types of events. Intermediate events can be used to define alerts for BAM tools and all kinds of management notifications. Perhaps this disconnect is because TIBCO does not consider BAM part of BPM. They have a totally different toolset for event processing. However, for our purposes this is a fatal flaw and won’t allow us to fully describe what we need to.

Guess it’s on to the next tool, and in the meantime, Brenda definitely has a leg with her cool tablet computer. We have until Friday to get our first set of models done. Will let you know how it goes.

In the meantime, is anyone using a modeling tool that sounds like it will fit the bill? Would greatly appreciate your suggestions.

Posted by bethgb in SOA Design | Permalink | Comments (5)

Recently a company asked me about a design modeling method for doing domain analysis. Thinking that I actually did know what the term meant I started doing some research and soon realized that there is not actual agreement on the term. The May 8, 2006 edition of Infoworld had a whole section on “Organic SOA: Creating a Sustainable Lifecycle” David Linthicum had an article on domain analysis, and his definition was what I thought I was going to find elsewhere. It was about a top down approach to defining web services.

However, a BEA whitepaper that has been liberally spread across the web that defines six SOA domain: (1) business strategy & process; (2) architecture; (3) building blocks which include both infrastructure services, business services, and composite applications (why aren’t infrastructure services part of architecture and why aren’t composite applications part of projects and applications?); (4) projects and applications; (5) organization & governance; (6) and costs and benefits. This is definitely not a domain model used for designing business services.

Then there is the programmers’ view of the world, which is important because they are the ones to implement this. According to Martin Fowler, a domain model is an object model that includes both behavior and data.However there is now quite a bit of scuttlebutt about an anemic domain model for SOA where the behavior is not there. Apparently some programmers think this is better for SOA design. (See Andres Aguiar and Carols Perez ).

Apparently, a domain model means different things to different people. What does it mean to you? What types of models are you using to design business services?

Posted by bethgb in SOA Design | Permalink | Comments (0)