Summary
The service architect is responsible for knitting the pieces together to solve business problems.
| Table of Contents |
|---|
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 , or for or even address for that matter, 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 and not understand . They will also not relate to the broad and sometimes tongue-in-cheek terminology.
A New Role
OSIDs We need to be applied to business problemssolve 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. Implementations 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 into 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.
...