I spent some time at the Software Development Best Practices conference in Boston yesterday. I wanted to check out two event modeling classes being offered by Mary Gorman of EBG Consulting. This was Gorman's inaugural presentation of her event modeling method, although, like any good modeler, she was basing the method on other tried and true modeling techniques. It was indeed interesting. She was presenting the method as a techique for defining requirements. I've been working on an event-driven service design method for the past year, so I naturally wanted to check out what others are doing in the field. Bottom line is that events are indeed important if we want to create agile event driven architectures. And we need methods to help people do this.

I became even more convinced of the need for new methods after attending some other sessions and looking over the full offering. There were LOTS of modeling and methodology sessions offered. Everything from UML modeling, agile Model-driven development, Scrum, process modeling, etc. In fact, what was in short supply at the conference was a list of sessions that began with the letters SOA. It was clear from the number of programmers in attendance that many were looking for new ways to improve the analysis, design and delivery of software. If they're not thinking much about SOA methods now, they will need to soon!

Surveys consisently show that a minority of companies have more than a few services in production. My guess is that even those that have many services deployed do not yet have repeatable methdologies with consistent artifacts. Without such methdologies, the success of the project depends on the skills and experience of the people doing the project. Design and development methodologies inculcate best practices and help reduce risk of failure. As SOA matures and implementations become more widespread, methodologies geared toward SOA implementations will become a requirement.

Posted by bethgb in Industry Trends | Permalink | Comments (2)

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)