Enterprise Integration Zone is brought to you in partnership with:

Masoud Kalali has a software engineering degree and has been working on software development projects since 1998. He has experience with a variety of technologies (.NET, J2EE, CORBA, and COM+) on diverse platforms (Solaris, Linux, and Windows). His experience is in software architecture, design, and server-side development. Masoud has published several articles at Java.net and Dzone. He has authored multiple refcards, published by Dzone, including but not limited to Using XML in Java, Java EE Security and GlassFish v3 refcardz. He is one of the founder members of NetBeans Dream Team and a GlassFish community spotlighted developer. Recently Masoud's new book, GlassFish Security has been published which covers GlassFish v3 security and Java EE 6 security. Masoud's main area of research and interest includes service-oriented architecture and large scale systems' development and deployment and in his leisure time he enjoys photography, mountaineering and camping. Masoud's can be followed at his Twitter account. Masoud has posted 82 posts at DZone. You can read more from them at their website. View Full User Profile

Project-Oriented SOA

08.18.2008
| 21148 views |
  • submit to reddit



Conclusion

Regardless of what the technology vendors would like you to believe, SOA is a complex concept. A number of elements need to come together to truly achieve service orientation. A lot of work needs to be done to establish a successful SOA program. Yet, all of this has to be done in conjunction with delivering projects. The business does not stop. It does not and cannot wait for the SOA program to be established, fully built out, and all the services delivered. Therefore, most SOA programs face the challenge of dealing with projects while at the same time trying to deliver on their high level promises.

To address the SOA and project goal incompatibilities, service lifecycle management, architecture, SOA governance, funding, and SOA metrics need to be brought together in a comprehensive program. Creating a central team to manage this process will result in more consistent deliverables, more efficient operations, less opportunity for political influence, and faster attainment of SOA benefits.

Projects with SOA potential should be considered part of the overall services pipeline. Cumulative requirements should drive service design and development. The service architecture needs to be flexible enough to accommodate changes, minimize the impact of service changes on the existing consumers, and maximize service reuse potential. SOA governance should influence the projects to make the right decisions and catch non-compliers if necessary. A comprehensive view of the project pipeline should make this process streamlined and efficient. Specially designated funding solutions should eliminate the disincentive for projects to build reusable services. Finally, the SOA metrics should demonstrate the achieved results and influence the right behavior. Figure 5 demonstrates the relationship between all the project-oriented SOA elements.


Figure 5: A view of project-oriented SOA.

Those organizations that embrace the project-oriented approach to SOA will have better success in SOA adoption and delivering results. At the end of the day, the business doesn’t care how many services have been built or leveraged. What really makes the business executives tick are the sales, new product introductions, new customers, real savings, achieved efficiencies, and everything else that deals with growing revenue and impacting the bottom line. Enabling business agility is the primary goal of SOA. Establishing an approach that delivers both the SOA program benefits and business goals of faster time to market and cost savings will undoubtedly make IT and the whole organization successful.



References

[REF-1] SOA Design Patterns (Prentice Hall), www.soapatterns.com
Published at DZone with permission of its author, Masoud Kalali.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)