Most of my projects are "real world," and as such things are never perfect. While most think about SOA as the design and development of these new shiny services that are perfectly designed, tested, and implemented, the real world is that most services leveraged within an SOA are from existing interfaces (e.g., APIs) that are abstracted, and exposed as services. That being the case there has not been much thinkin Most of my projects are “real world,” and as such things are never perfect. While most think about SOA as the design and development of these new shiny services that are perfectly designed, tested, and implemented, the real world is that most services leveraged within an SOA are from existing interfaces (e.g., APIs) that are abstracted, and exposed as services. That being the case there has not been much thinking around this approach, which is a bit different than designing and building services from scratch. So, how to you approach service design for services that are externalized from existing interfaces? It’s really a matter of understanding, defining, and designing. Understanding First, you need to figure out what you’re dealing with. There are many types of interfaces that can potentially become services. For instance, APIS, user interfaces, transactions, and direct-to-hardware interfaces (e.g., impeded interfaces). Each type if interface requires different approaches, techniques, and enabling technology. Here, it’s best to work back from the interface to a level of abstract data and behavior…that’s how you’ll feed your services. Defining Next, you need to define the interface at a high level. Typically, they produce or consume information, but may provide more direct access to behavior as well. Thus, define the structure of the information, and the functions that act upon the data. In other words, what are the raw structures, and what behaviors are externalized along with the data? Designing Once you understand the mechanisms to deal with the interface, and the meta-service information (data and behavior) around it, it’s time to design the service. I’ve written a lot on service design, so I won’t discuss it here. However, what is different with externalization, when it comes to service design, is that you really should consider the layers of abstraction under the service, and the unique nature of those interfaces and how they drive design. You’ll find that the interface mechanisms really control how your services are defined, designed, and implemented. For instance, it’s difficult to normalize services that are bound to interfaces…one interface-one service. Therefore, it’s difficult to break apart the services as autonomous units since they in essence reflect an abstraction of the interfaces, and are indeed tightly coupled to the interfaces. Not pretty, but not ugly either. Good luck. Software Development