zenAptix ^{Open Source Solutions}

• Consulting (Architecture and design)
• Reference Architecture (Technical)
• Qualified SOA architecture
• Technical Reference - A Developers Handbook
• SOA Technical Governance
• Product training and support

Despite all the claims by "marchitects" (Marketing Architects or software vendor salesmen) to the contrary, Service-Oriented Architecture is not new. It is based on well known principles and industry best practice that were established in the 1990?s when it became apparent that dependencies between software components must be minimized. This gave rise to the principles of

• encapsulation (hiding the details of an object that do not contribute to its essential characteristics);
• location independence - services must behave consistently, anywhere, anytime and
• programming-by-contract - software designers should define precise checkable interface specifications for software components.

With these principles in mind our very experienced consultants are able to quickly deliver real business value.

The Reference Architecture articulates the architectural vision of the SOA implementation and aims to give you:

• A qualified SOA reference architecture against which vendor and open source products can be benchmarked for open standard compliance;
• a Template SOA infrastructure;
• SOA Patterns, Business Patterns, Integration Patterns
• a SOA Security Model
• a Developers Handbook describing a robust System Development Life Cycle based on industry best practice;
• Lower risk in going forward with business requirements.

The developers handbook defines a set rules that aims to regulate the software development effort for SOA enablement. The environment must accommodate and support:

• your software strategy with regard to language and architecture choices
• in-house and outsource development;
• your system development life-cycle support; and
• component architecture with a strong focus on reusable functionality.

The handbook covers all aspects of development:

• project definition and management through a Project Management Framework;
• source control management;
• test driven development;
• automated and continuous build support;
• coding standards
• naming conventions
• documentation;
• transparency of the development cycles through the publishing of metrics on all aspects of these cycles; and
• release management;
• a qualified SOA reference architecture against which vendor products can be benchmarked for open standard compliance;
• fully deployed and tested SOA infrastructure;
• a Developers Handbook describing a robust System Development Life Cycle based on industry best practice;
• lower risk in going forward with business requirements.

Some vendors attempt to shroud SOA in mystery. With this they aim to push their product with claims of enabling developers to do SOA without having to bother about the underlying technology. This quick productivity ramp-up is a tempting proposition, but more than often it leads to unmaintainable code and vendor lock-in. SOA is not new - it is another case of the computer industry reinventing itself - or rather using new terminology to describe well established patterns.

One of the drivers behind SOA is to overcome the problems that system architects and developers have with the development of distributed component architectures. The technical principles and development patterns provided by this project serves as a guide to which architects must adhere. These design principles are tested during the reference implementation:

• Services based. The fundamental element in SOA architecture is the "service." A service has certain responsibilities that can be used by the rest of the enterprise.
• Loosely coupled. The client (other services, end users, or external programs) leveraging the services need not be aware of how the services fulfill their responsibilities. Internal data structures, calls to other services, transaction management, and storage requirements should be hidden from the client.
• Location independent. The client need not be aware of where a service resides or executes.
• Interoperable. Services should be able to exchange data amongst each other. Many component architectures are based on proprietary protocols and implementations. In contrast, standards-based protocols support free interoperability between multiple vendor products.
• Combinable. Services should be designed and implemented such that they can be combined to create new services.
• Business aligned. Services exposed to end users or external programs should represent business process functionality. The inputs/outputs they expose should be expressible in terms of business-aligned needs.