SOA in the DOD / Government

I just had the opportunity to participate at the latest SOA Symposium focusing on the Department of Defense and other government agencies. The theme was on the people aspects of SOA and how success is directly measured by the amount of collaboration and teamwork in the project.

Vendor presentations by IBM, Microsoft, Oracle, Red Hat and Amberpoint talked to Cloud Computing, SAAS, Event Processing, Open-Source and Governance.

Separate to this I have had the opportunity to do some training and consulting in the area exposing me to the contracting base and additional government agencies. It is clear that data sharing between agencies appears to be increasing and currently service APIs are seen as the goal.

SOA Architecture and Agile Methodology

Over the past couple of months I have been exposed to colleagues, professional acquaintances, and training that has discussed the merits of Agile Methodologies in creating a loose but improved development organization. One client that I work for has several teams that are employing short iterations and have improved their overall deliver of software functionality. The company has also spent time training the teams via experienced Agilists and employed collaboration software to support epics, mrf, user stories, product backlog etc.

Working in the architecture group, there is currently no process in place but we are considering applying Agile and short 2 week iterations to deliver value to the product teams. In essence have the product teams help define challenging issues to be solved to free them up and allow them to focus on their tactical user stories/development tasks. In addition having the architecture team sit in on the product teams iterations to identify / guide the development teams towards existing services in the domain/enterprise to reduce/eliminate rebuilding existing logic. This can be done by participating in the Iteration Planning Meeting at the beginning of each iteration.

From these experience I will be trying some role/organizational approaches towards SOA in an Agile environment. They include setting up clear versioning policies for the service contracts and using design patterns to decouple the contract from the logic. This will allow the contract to more easily change from its potential tactical definition to a more domain/strategic one.

How easy is SOA?

When reading blogs on SOA or technology in general, what strikes me is the amount of misleading information that exists in the space or even worse, the lack of information. When tackling new technologies in open source or standards, the lack of documentation or practical information is quite often missing. Once in awhile, I find a clear and concise document that is able to help me learn a technology rapidly. An example of this was some work I was doing debugging a Hibernate issue. To really understand the process/facilities that Hibernate provides, the base documentation provided a solid basis and was able to get me to completion within a couple of hours.

Compare this with work I was doing with some WS Standards, where the only information I could find was the specification and a poorly documented reference implementation.

As part of my business diversification towards providing training in the SOA and Open-Source marketplace, I will be trying to distill how SOA, the available tools and design standards can be applied to people that have little to no experience. An example of this is a group of QA personnel who I will be training in SOAPUI.

Another group I am training is around building a SOA Application that is front-ended by FLEX and back-ended by MySQL.

My current experiences is always focused on the KISS principle. Don't assume the audience is familiar with XSD, WSDL, Service-Orientation etc.

To date these students are getting the examples and are helping evolve these heterogenous scenarios into potentially valuable training offerings. So I can definitely answer that SOA is not easy however if approached properly, a wide audience can participate and incorporate the core principles and technologies.

"SOA is Dead" Questions

Anne Thomas Manes from Burton Group recently posted an article related to the Death of SOA. Many customers that I work with who are in the middle of SOA Projects had questions on the article. Anne's presentation on SOA Fatigue at the SOA Symposium was also a prelude to this posting. If one examines the article, you can draw the following points:


- SOA Technologies from various vendors have become obtuse, costly and difficult to implement
- Enterprise SOA success in the marketplace is limited to a small collection of customers and is not widely seen due to the amount of effort to establish the entire Inventory.
- Service-orientation principles are still valid and important in providing value to the customer.
- Services should be the focus not SOA.

If one is attempting to apply SOA to a domain or Enterprise, we should revisit the goals of SOA:

- Intrinsic Interoperability
- Vendor Independence
- Increased Federation
- Business and Technology Domain Alignment
- Increased ROI
- Organization Agility
- Reduced IT Burden

These goals are then supported by the following principles of service-orientation

- Standardized Contract
- Loose Coupling
- Reusability
- Abstraction
- Autonomy
- Statelessness
- Discoverability
- Composability

The application of service-orientation helps guide business analysts and architects towards resuable, agnostic services. By following these principles, we in affect are directly supporting interoperability, vendor independence and federation. Service development also benefits from business and technology domain alignment when analyzing existing processes in an Inventory Analysis.

The success of customers I work with has been on supporting a domain versus the entire Enterprise. Success of the domain efforts in several cases has caused the business side of the organization to consolidate functionality in other divisions to leverage the domain services and their demonstrated benefits.

The key in Anne Thomas Manes blog is that the fundamental piece of SOA, the service, is still important. A service is logic that has applied service orientation to a meaningful extent. This in combination with SOA Design Patterns provides the architect/developer with a solid foundation for realizing the benefits. How you the develop, register, host, monitor the service can be done in a heterogeneous way with a wide range of standards, technologies and patterns.

SOA Design Patterns Online

In a previous post I talked about the first SOA Symposium held in Amsterdam last October. One of the book releases from Thomas Erl was SOA Design Patterns which is now available in an updated form online. Check out www.soapatterns.org. In addition to the published patterns are candidate patterns around REST, binary data transmission and others.

WOA versus SOA

My discussion point in my last entry discussed how SOA is agnostic in which technology should be used to employ it. Joe McKendrick and Dion Hinchcliffe at ZDNet along with research I did for a client identified a growing interest in using REST to support SOA. ZDNet refers to it as Web Oriented Architecture, a subset of SOA.

Dion Hinchcliffe's discussion on WOA

Some points that are referred to in these articles identify these characteristics:

- HTTP(S)
- POX
- JSON

Effectively from the runup of Web 2.0 technologies, the ever increasing amount of public APIs, and the increasing amount of mashups that are being performed, Web Resources are more available then Web Services. WOA is being identified as the necessary amount of complexity to get the job done.

If we compare WOA to SOA, there are some distinct differences with one distinct one being the Service or Resource Contract. WSDL/XSD/WS-Policy are front in center for describing a Web Service. Within REST, the contract is implicit and is based on HTTP verbs and XML Schema. If developing a web service, the contract analysis, design and development effort is the main focus whereby the service foundation layer and data representation layer are identified. In WOA, the data representation layer is the focus instead.

Web Services != SOA

During a recent trip to a company technical summit a discussion came about related to how SOA is just Web Services. As a SOA Trainer, Architect and Implementer I live and breath it every day. Most peoples perspectives probably fall in this category and currently most of the SOA implementations that I have worked with have used Web Services. The key is that Web Services is just an implementation technology not a SOA.

Books from Thomas Erl, Intel Press and others have identified that SOA is a design paradigm that focuses on a series of principles that tie back into key business goals and benefits. Examples of these are presented at SOA Systems but include:

- Interoperability
- Federation
- Cooperative Development between Business Analysts and Technical Architects
- Vendor/Technology Choice
- ROI
- Reduced IT Effort
- Business Agility

Now a SOA could be constructed using CORBA, Java, SCA/SDO, Web Services, REST etc. The implementation mechanism that one chooses should support interoperability, federation etc. Currently XML Based technologies provide the best interoperability both in communication/exchange but in vendor support, standards, tooling but this may change over time and probably will.

So if a person asks me what SOA is, I simple identify it as a design paradigm for developing and evolutionary distributed architecture. It has its basis in OO, AOP, EAI, BPM and other styles. It is like the Bruce Lee of architectures having evolved from various fighting styles.