I typically write articles that emphasize technology, such as "Use Enterprise Generation Language (EGL) in a Service-Oriented Architecture." (Subscribers can read this article at http://My.Advisor.com/doc/17767.) Essentially, that article discussed the nuts and bolts of constructing a Web service in an SOA. Web services technology is becoming fairly mature, including the WS-* specifications. What appears to be lacking is a clear purpose for Web services and a methodology that addresses the unique attributes of an SOA project. If an organization doesn't have basic process and control procedures in place, moving to a more advanced SOA, one that includes an Enterprise Service Bus (ESB), will be difficult. A concise definition of ESB can be elusive, but basically, an ESB has routing, transformations, protocol support, orchestration, and integration capabilities.

New distributed architecture

Some technologists measure Web services' great grandfather, CORBA's, maturity with respect to the number of program language bindings available as an indicator of maturity. In comparison, Web service clients can be a JavaServer Page, servlet, or Java application, or an executable written in languages such as C++, Perl, Visual Basic, or JavaScript. With respect to Web services in an SOA, you must determine when and where to deploy a true Web service and the appropriate modeling artifacts and specification approaches. However, organizations often have limited tolerance for protracted analysis and system design lifecycle phases; even though meta-data and model-driven programming are the wave of the future, whether the implementation is a Spring Web Flow or a standard Web service. (For more about Spring Web Flow, see my article at http://My.Advisor.com/doc/17767.)

Mission important, but not necessarily critical

My EGL article discusses exposing an EGL program (a fourth generation language for J2EE used by non-Java programmers) that integrates with MQSeries as a Web service. What the article doesn't discuss is when this type of architecture is appropriate.

Web services are, for the most part, an improvement in B2B technologies and standards for the Internet, including XML. An SOA doesn't necessarily mean you must expose all services as Web services, but there's a strong case for implementing B2B functionality as a Web service. So, during the discovery phase of an SOA project, a good candidate for a Web service is B2B functionality. Conversely, the technology doesn't have to be limited to B2B. It does represent a bridge technology for communicating between disparate environments; however, the SOA model, which uses Web service as its enabling technology, addresses a more complex problem set.

Yet another methodology

The purpose of this article is to help you develop a unique philosophy and position regarding implementing an SOA. The results over time could develop into a methodology you can use in a project plan where SOA is a partial requirement or the focus of the project. In contrast, Rational Unified Process (RUP), a methodology for designing and building object-oriented (OO) systems, developed over time and represented the "unification" of many OO methodologies.

An SOA methodology represents a set of tasks and associated artifacts focused on creating and maintaining an SOA (figure 1). Some of these tasks would be represented in any forward engineering development project, but some are unique to SOAs. Forward Engineering is the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of a system, as compared to reverse engineering.

In general, SOA projects have some of the features of a portal project and some of the features of integration projects and some of the features of application reengineering projects. Indeed, an enterprise-wide SOA spans legacy as well as new technology. Some analysts refer to this approach as "legacy abstraction" services -- services built on top of existing services, including technology, such as COBOL and CICS on mainframes. The concept is to externalize these older internal processes as services and surface them as modern Web services.

SOA assessment

One artifact that seems to be emerging as the de facto initiation of an SOA project is to perform an SOA assessment. BEA and IBM have online SOA assessment models, and I highly recommend taking those assessments. But beware, because the vendors are setting the stage for creating the need for their Enterprise Service Bus (ESB) technologies. The marketing message implies that if you don't have an ESB, it isn't an SOA, although I've seen technology departments develop an ESB based on the Spring Framework. Therefore, ESB doesn't necessarily only imply commercial off-the-shelf solutions (COTS), but trying to develop a custom ESB is beyond the capabilities of most organizations.

A [nascent] SOA project methodology

During a rigorous SOA assessment, the SOA team gathers existing artifacts as well as creates new ones. You should revisit the artifacts you collect or complete during an SOA assessment during the lifecycle of a full SOA project.

You should discuss the following subjects and factor them into appropriate tasks for the assessment:

Digital Strategy -- Today, IT executives in most organizations clearly indicate a strategic intention to move to an SOA. However, there may be little evidence of any progress toward achieving that goal, whether through organizational change, standards bodies, or a review of the enabling technologies and reference architectures used in recent implementations. You want to answer these questions:

• In the organization strategic or technology plan, if it exists at all, are there any references to pursing an SOA?
• Is there a compelling business strategy that can be achieved through the tactical deployment of Web services?
• Most mid-size to large organizations have a five-year technology plan, so site the substantive reasons in the document for moving to an SOA?
• What is the organization's tooth-to-tail ratio regarding this architecture (that is, the number of qualified Web services developers, as compared to management staff)?
• Does the organization view SOA as an alternative to conventional architectures that will shorten project timeframes?
• Does the organization view SOA as a model appropriate for all IT projects, or does it have a discreet view of when the development team should apply the model?

SOA Business Case -- Identify the driving force behind the organization's interest in SOA and Web services by asking these questions:

• Is the organization's interest based on the need to stay current with technological advances?
• Is there primarily an architectural reason, such as the need to bridge Microsoft technologies on the desktop with back-end J2EE applications on UNIX or mainframe computers? Or does the organization lack an enterprise-wide remote invocation framework standard and Web services would provide that mechanism?
• Is there a mission in the organization to foster reuse at the services, Web flow, or (object/component) level? Or instead of reuse, should you design and build a service in such a way that intranet, extranet, and Internet applications can use it?
• Has a business partner requested you expose a service as a Web service?
• Does the organization view SOA as a tactical solution instead of an enterprise-wide strategic solution?

Technology Risk Aversion -- Assessing the style of the organization with respect to adopting new technology (that is, cutting edge vs. conservative) is important. Use these questions to help make your determination:

• Is the organization willing to embrace standards that aren't complete or technologies that, because they might represent beta releases, may not be as stable as conventional alternatives? In general, a number of the WS-* specifications submitted to the World Wide Web Consortium (W3C) are considered rudimentary, in comparison to the Sun Java Platform, Enterprise Edition 5 (Java EE 5), formerly J2EE, specifications.
• Does the organization view technology as a competitive advantage or simply as a cost of doing business?

SOA Analysis and Prioritization -- Based on corporate project planning and business strategy, you must prioritize SOA projects with respect to project dependencies and business importance and complexity. Some analysts refer to this activity as options analysis and Gartner uses the Magic Quadrant to identify which projects are of strategic importance.

• Even though the organization strategic intentions include an SOA project, is the IT organization ready to develop and maintain an SOA?

Non-Functional Requirements -- Identify a set of SOA non-functional requirements, such as response times to guarantee (to internal or external customers), transactional integrity in long-running workflow scenarios, etc. Organizations often overlook non-functional requirements or quality characteristics, which are difficult to understand when compared to Functional Requirements, such as Use Cases, Business Rules ("Shall" statements), and feature lists, which are more intuitive.

• Does the organization have existing service level agreement (SLA) requirements for application metrics (e.g., how fast a report should display)?
• Does the organization have non-functional [supplemental] requirements that specify system properties, such as environmental and implementation constraints, performance, platform dependencies, maintainability, extensibility, and reliability for applications Web services and an SOA would have to conform to?
• Does the organization have clearly defined Web service latency expectations?

Constituency Analysis -- Model the users of the system and their roles to determine Web services privileges.

• Does the organization use UML? If so, modeling Web services Use Cases and associated actors is a good way of defining roles and privileges for the SOA. An actor is a person, organization, or external system that plays a role in one or more interactions with your system.

Current Security Infrastructure -- Web services security model defines how authentication and Role-based access control (RBAC) is implemented with the service.

• Does the exiting enterprise security system support standards, such as Security Assertion Markup Language (SAML), Xtensible Acess Control Markup Language, XML Signature, XML Encryption standards?
• Does the organization currently use Universal Description, Discovery, and Integration (UDDI) or lightweight directory access protocol (LDAP)? If so, you should have a directory for services discovery to find and leverage the services. You could contain this information in UDDI or LDAP directory services.
• Does the organization have a well-defined security reference architecture for distributed systems, such as a distributed computing environment (DCE), CORBA, J2EE, etc.?
• Does the organization have a single sign-on (SSO) technology in place?

Architectural Review Board -- Propose establishing an architectural review team that has a good grasp of the existing standards and technologies. Establish where the review board fits into the existing organizational "reports to" chart. If the review board doesn't have a certain amount of political capital in the organization, it's destined to be ineffective.

• Based on the organization risk aversion to technology, which standards does the board deem, at this time, to be mature enough to embrace?
• Is the review board familiar with establishing governance principles in other application domains?

Governance Principles -- Identify existing governance principles (i.e., loose coupling) and develop a set of best practices for SOA and Web services design and development. For example, you should establish governance principles regarding when to use coarse-grained vs. fine-grained services.

• Does a set of governance principles exist for any technology in the organization, that is, portal, enterprise resource planning (ERP), etc.? SOA has some features similar to other enterprise-wide applications; you can reuse artifacts, such as governance principles, to a degree.

(High-level) SOA Specification phase -- Based on corporate models or joint application development (JAD) sessions, begin to model the behavior of a candidate Web services.

• Does the organization maintain and design corporate business models, such as, process models, activity diagrams, Data Flow Diagrams (DFDs), Domain Models, etc.?
• Or does the organization typically use a prototype to specify application behavior?

Findings and Recommendations -- Based on the existing artifacts and artifacts you created during your assessment, document the important findings and recommendations, such as the need for technical expertise or the set of WS-* specs that will be embraced.

Implications

At the minimum, you should identify a set of SOA artifacts before pursuing an enterprise-wide SOA. I've been part of efforts where high-level executives have attended meetings where gurus evangelized SOAs. In turn, the executives proclaimed to the technology group that they must pursue an SOA. The technology group then started to implement Web services with no concept of standards or a real understanding of how the technology would be used appropriately or managed within the enterprise. Needless to say, the effort failed because of technical and managerial reasons.

Remember: a carpenter is known by his tools, but good tools don't necessarily make a good carpenter. There is clearly more to SOAs than technology, and hopefully this article will help get you started on the right path.