email article printer friendly

Going to SEA with Flashline
Look into optimizing business processes through a services IT model of your data and practices
by Charles Stack

April 13, 2005

Charles Stack

Charles Stack is the founder and CEO of Flashline Inc. He will be speaking at Enterprise Architect Summit (Key Biscayne, Florida, May 22–24) on "SOA and Enterprise Architecture: Integration that Works." Stack recently submitted written responses to several questions about Web services and SOA for FTPOnline.

FTP: What's the difference between Web services and SOA in the context of enterprise architecture?

Stack: Building a Web service is trivial compared to developing an effective service-oriented architecture (SOA). A Web service is merely a handful of methods exposed over TCP/IP and delivered in XML. An SOA provides the standards and practices that govern and direct the development of your enterprise's Web services. The SOA must be developed as a subset of your overall enterprise architecture. The goal of EA generally is to provide IT with a sense of time—a sense of past and future that exists beyond the myopic focus of the current project. That's the same goal for SOA—to provide a guide for future Web services and to maximize the value of existing Web services. At Flashline we use the term Service-Oriented Enterprise Architecture (SEA) to reflect the importance of combining these two concepts.

FTP: How do you maximize the value of your Web services?

Stack: That's a real softball. You need to do three things: design, document, and distribute. Web services must be designed for reuse by ensuring that they are loosely coupled, cohesive, standards compliant, and follow enterprise naming conventions. A certain type of documentation is also essential. You must create documentation designed to allow and encourage others to use your Web service. So things like usage examples, FAQs, code samples, test scripts, appropriate metadata, and other "commercial quality" style documentation artifacts are necessary.

Finally, if you build a Web service and nobody knows about it you have really failed to deliver maximum value. If your Web service is secret, when someone else needs similar functionality they will waste time and money recreating your wheel, while adding unnecessary duplicative IT cost and complexity. Distributing services is essential to success. And while you're preparing to make Web services available to developers, you need to keep in mind that Web services don't exist in isolation. They depend on code components, applications, and platforms. For maximum benefit, it is essential that your services be managed along with all your other software assets.