>SOA Best Practices

>I came across these Service-Oriented Architecture (SOA) best practices and thought they aligned well with User-centric EA and were worth sharing:

(adapted from Naval Post Graduate School, Monterey, CA, Masters Thesis—SOA for Coast Guard Command and Control by Dash and Creigh, March 2007 — approved for public release):

  • Know when to use services – Explicitly define the extent to which we will and will not use services; services are selected with intent and do not randomly spring up.
  • Think big, start small – This allows us to validate the architecture, while giving the organization value, realized as usable services.
  • Build on what you have – Reuse legacy application functionality and data wherever possible.
  • Use SOA to streamline business processes – SOA is an inherently flexible and interoperable model for hosting application functionality; this provides an opportunity to rethink and improve business processes.
  • Incorporate standards – Use industry web service standards for navigation, application logic, integration, data stores, and enterprise infrastructure.
  • Build around a security model – Functional design needs to be built around security, and not vice versa (security cannot be added as an afterthought).
  • Design with quality in mind – Quality must be designed into the product, and not inspected into it.
  • Organize development resources – Group development team around logical business tasks, and not around technologies.
  • Train developers – Ensure designers and developers have the skills to implement SOA properly.

Basic definitions:

SOA is a software design methodology that uses loosely coupled services to perform business functions and processes.

A service is an implementation of a well-defined piece of business functionality, with a published interface that is discoverable and can be used by service consumers when building different applications and business processes.

In general, I think SOA is a great fit with User-centric EA, because the focus is on providing functional business services to the end-user, as opposed to developing monolithic, stove-piped, and redundant applications. The end-user should not have to use countless non-integrated applications systems (or even computers) to get their information, but rather the information should be technically transparent and readily accessible based on their business requirements.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s