In-Depth

Going to SEA with Flashline

If a service-oriented enterprise architecture can build an IT model of your business data and practices, then you can optimize those business processes. That''s where the money is.

• By Charles Stack
• April 13, 2005

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.

FTP: Can you elaborate on the type of augmented metadata that's needed to maximize the value of your Web services?

Stack: You need to put yourself in the shoes of a development team seeking to use a Web service developed by others. What would you want to know? You would want to know things like: who built it, when was it built, for what project, what was its original purpose, past and forthcoming versions, reliability data, response times, provisioning responsibility, licensing, and costs. The most valuable data is that which accumulates over time. Things like: Who else has used it? What was their experience? How can you contact them? What other Web services or assets are usually used in conjunction with this Web service? Providing this type of continuously increasing context around each Web service dramatically increases the ease of reuse, and thus the return on each Web service.

FTP: What's the biggest mistake you see?

Stack: By far the biggest mistake we see is the failure to get control over the proliferation of XML schemas. We see companies building Web services all over the place. And in the process they are necessarily creating XML schemas to represent corporate data. And they are not doing it in any sort of systematic fashion. The result is not increased agility, but a literal tower of Babel, where systems can't talk to each other because they are literally using a different language. My customer.xml is incomprehensible to your customer.xml. This doesn't mean you need the French Word Police, but it does mean you need centralized storage, control, visibility, and publication of XSD files.

FTP: You mentioned "compliance with naming conventions?"

Stack: That's certainly part of it. You absolutely should have centralized namespaces. But at least make sure that there is maximum visibility of your schemas. With Web services you are modeling the data of your business. Just as you need to control relational database schemas, you need control over XML schemas. Controlling and publishing XSD metadata in a registry should be the first thing your SEA team does.

FTP: What's the biggest benefit of implementing a SEA?

Stack: Once you accept that implementing a service-oriented enterprise architecture (SEA) is effectively building an IT model of your business's data and its practices, then the obvious step is to use this as an opportunity to refine and optimize those business processes. That's where the mega-returns lie—not in moving your existing business processes to Web services, but in improving your business through the implementation of a well-designed SEA that optimizes the way your business runs.