This is part of a series of blog post about Applied SOA. The past blog entries are:
In this article, I’ll cover the Service Discovery Process. You’re working on an SOA project. There’s going to be services. What are those services?
That sounds like a trivial questions but it’s actually quite fundamental. There are two extreme approaches I know about.
The first approach, also called “bottom-up”, basically consists at looking at what applications needs and trying to generalize it to the Enterprise level. This approach is actually quite popular because most SOA efforts start with one project, a new application, and therefore it is quite natural to look at that application to decide what you want to expose in your Enterprise at large.
Now that approach is application centric by nature. Your viewpoint is the tree (the application) not the forest (the entire Enterprise). So yes, you can guess from this new HR system you’re deploying that having an employee service is a good idea, but what type of employee schema makes sense at the Enterprise level (cross applications) and which operations would make sense to be exposed at the Enterprise level? The application won’t tell you that. You can speculate, everyone around the table will have a different idea.
That approach is quite good at picking reusable ‘utility’ services, e.g. Enterprise Login, Pub / Sub, Transformation Service, Communication, etc. . You can often pick some data services that would make sense at the Enterprise level too. It is wise to go easy on those one and deploy a minimalist version 1 so that you have elbow room to take more decisions by the time you connect other applications on it.
It is quite rare that you raise to Business Processes using this approach and if you do you’ll have the application’s view of a Business Process.
Now let’s look at what some SOA gurus think of this approach. Philip Wik, in an SOA Magazine article mentions:
But, as a question of architecture and strategy, a populist approach is like building a new house around its appliances. A bottom-up approach introduces needless complexities into already complex systems that are at cross purposes with the company’s umbrella strategy.
(emphasis mine)
Thomas Erl, in one of his books (SOA Concepts, Technology, and Design, 2005), says:
The bottom-up strategy is really not a strategy at all nor is it a valid approach in achieving contemporary SOA. […] Although the bottom-up design allows for the efficient creation of Web services as required by applications, implementing a proper SOA at a later point can result in a great deal of retro-fitting or even the introduction of new standardized service layers positioned over the top of the non-standardized services produced by this approach.
(emphasis mine)
Not such a popular approach in the SOA circle as we can see. Why is it so popular then? Well, let’s look at the other extreme approach, also called the “Top Down” approach. This approach starts with the Enterprise business process and identifies each activity that should be implemented by a service.
For instance, let’s take my company (fictitious, I made it up) on boarding process. This process is represented using Business Process Notation (BPMN). It represents the process and is entirely agnostic of the systems & technologies.
Each task (square) in this diagram becomes a potential service operation. This approach is of course task-centric and doesn’t give a very good view on the data.
Why approach is better? Well, guess what, it depends!
The first approach is easy but doesn’t capture Enterprise needs. The second approach is less trivial (you’ll need to speak to a lot of departments to get your head around a process sometimes) but captures the Enterprise needs with no noise about the technology.
Typically, the two approaches should be used together and meet in the middle. On one hand you analyse the Enterprise Business Process, on the other hand, you analyse services from different systems. When you identify services with both approaches, you probably have a good candidate for promotion to Enterprise Service while improving your chances of reuse. You can still piggy back your first big project involving services which tends to happen anyway.
What I often see is a bottom-up approach with some Enterprise inputs, such as an Enterprise Data Model and some Enterprise business rules. This typically leads to Data Services centered around key Enterprise concepts exposing Enterprise Data. It’s not the full-blown SOA promise, but it’s a good foundation for future SOA projects: you need to start knocking down data silos before orchestrating cross-business-units process.
Vincent-Philippe Lauzon's 
8 thoughts on “Applied SOA: Part 3 – Service Discovery Process”