When I read Clemens’ post "Autonomous Develop Services for SOA Projects with Team Architect and Service Factory", I realized that part of his approach may integrate very well with the Macaw Solutions Factory.
Clemens describes how to enable each service in a SOA to be developed by a different team while still keeping the overall SOA design in one place. He partitions the SOA implementation across separate Visual Studio solutions (a single master solution containing the service models, and a separate solution for each service).
The Macaw Solutions Factory has had autonomous service development designed in from the start, it is a core concern addressed by the architecture style MAST (Microsoft .NET Architecture Style) that is at the heart of the factory. MAST also supports distributing a single large service across multiple solutions, and it specifies a standard pattern for dependencies within and across solutions. The factory supports independent versioning of each factory instance together with the service/application it is building while still using shared DTAP environments for the SOA. This makes service maintenance even more flexible and autonomous. So we got that part covered, it proved to work fine for a couple of years now.
.gif)
Dependencies across projects and solutions in Clemens’ approach
Dependencies across solutions within a MAST service / application (dependencies across projects are standardized on the three-layered services application pattern).
However, Clemens also devised a way to keep the overall design of the SOA in a separate solution, by means of clever application of the P&P service factory and the distributed system designers in VS Team Architect. Overall SOA design is an area not yet addressed by the Macaw Solutions Factory (the focus is on building services and applications that are first-class SOA citizens, not on maintaining overall SOA design), and Clemens’ approach for that may integrate very well into our factory.
We already plan to integrate the Orcas version of the P&P Service Factory into the Orcas version of the Macaw Solutions Factory (we actually prototyped the approach during the Service Factory Customization workshop, Don and Olaf were a great help there). Thanks to the excellent extensibility of the service factory this is a real breeze (great work, guys!).
The extensibility built into the service factory looks to be a real enabler for the composability of a certain class of factories. It’s great to be able to combine approaches pioneered by different people in the factory community. Sometimes life is real easy 🙂
