The Audience

Summary

The service architect is responsible for knitting the pieces together to solve business problems.

Flying Blind

OSIDs are an architectural tool. These specifications are meant to be applied to solve integration problems. OSIDs lay down the tracks to guide analysis and development of new systems. They do not optimize for or even address the tools and development environments to which programmers are accustomed although it is expected that the OSIDs will be applied to them. They also do not directly speak to business users who will trip over the service factoring. They will also not relate to the broad and sometimes tongue-in-cheek terminology.

A New Role

We need to solve business problems. Service Design Methodologies such as the OSIDs help preserve the development investment in business solutions. Services are not a business solution in itself. Applications need to be mapped to service operations and data. Service implementations also need to be mapped or designed. Appropriate services need to be selected. Integration points need to be understood and the existence of rules identified. This is the job of a service architect.

Don't throw OSIDs or any other service framework into a project and expect magic to happen. OSIDs didn't graduate from Hogwarts.

The Service Architect

The role of a service architect works the middle ground in the what we need now, where we are going, land of integration. In enterprise projects, the service architect works with all of product management, development management, functional business, UI design, service implementation, and middleware infrastructure. This is its own integration problem!

A Service Design Methodology like the OSIDs is helpful for making sure it all comes together and lowers the risk a project will paint itself into a corner. The caveat is that the OSIDs will initially not speak to any of these parties and it will feel like throwing a monkey into the wrench. The service architect is the translator into the neutral territory of service design. The service architect often has to be able to focus in those areas most important to a project and hide the rest.

Over time, however, a project will  more naturally align along service boundaries. It seems to do so because there is no other design methodology that crosses all the disciplines and can live beyond the latest design fad. Depending on the project, terminology alignment may be very difficult requiring the service architects to quarantine OSID terminology from some parts of the project.

From the service architect's point of view, application components and service implementations are developed piece by piece. The service architect has the proper vantage point from which to see other possible combinations, opportunities for reusability, repeating patterns, and piling OSID Providers on top of each other to solve new problems. A service architect doesn't decide if something should be implemented and having good developers means the developers themselves are capable of deciding how. A service architect directs where the problem ought to be addressed among a growing set of layered orchestrated services. This is a more difficult than it sounds.