Actionable SOA Design

The “TEC” & Innovation At Teksouth, Innovation is not a mandate, it’s our passion…

What is the TEC ?

Teksouth Corporation’s Enterprise Consulting (TEC) group is a professional services organization whose primary focus is delivering comprehensive next generation information technology solutions.

These solutions include SOA implementations, The “Dynamic Data Warehouse” or “DDW” as well as the Virtual Healthcare Portfolio. These are designed to facilitate enterprise scale integration.

The TEC is chartered to update and infuse Teksouth’s Solutions with leading edge technologies and techniques. We have developed a practice methodology based upon Semantic Interoperability which we refer to as the “i-TEC”.

What is Actionable SOA?

Actionable SOA represents actual implementations of IT capabilities; not designs, not proofs of concept, not prototypes.

Actionable SOA recognizes the full lifecycle and all elements of a Services Oriented Architecture solution as being bound within one governance framework.

Actionable SOA is performance-based, performance engineered and end-user focused.

Actionable SOA recognizes that most SOA Initiatives are part of enterprise transformations – those expectations should be the primary drivers for how a SOA project is run. The main purpose of SOA is to orchestrate enterprise capability .

The TEC SOA Practice

Elements of Our SOA Practice Services Oriented Architecture, viewed as an enterprise solutions practice, consists of a number of elements:

Enterprise Architecture, Solution Architecture & Solution Design

Lifecycle Management & Governance

Infrastructure

Integration

Legacy Transition

While many state that SOA only involves category one, that is a bit disingenuous. SOA solutions are like any other IT solution and as such must address all implementation issues in order to succeed. In our TEC SOA series, we will cover all of these topics in more detail in separate presentations.

Core SOA Principles

Loose Coupling (federated integration)

Abstraction

Service Reusability

Service Composability

Service Autonomy

Service Discoverability

Service Encapsulation

Use of the Service Contract

Modularity, Granularity, Interoperability

Standards-based

There a number of key design Principles that most agree are necessary for successful SOA solutions. Many of these are in fact the same as OOD principles:

TEC SOA Practice – EA & Design SOA is Enterprise Architecture, but it is also solution design. As such, it must meet certain requirements and expectations if it is to succeed, including:

Agility

Flexibility

Relevance

Traceability (from inception to retirement)

A Semantic Foundation

The TEC SOA Practice links all aspects of design with the rest of the SOA lifecycle continuum. We believe that architecture is important, but must be actionable for SOA to be Actionable. That means it must consider relationships, dependencies and performance expectations in the real world.

What is Enterprise Architecture ? It’s Big, It’s complicated and it includes SOA…

Enterprise Architecture & SOA There are few solutions integrators that have the skill and breadth of experience to support meaningful coordination of Enterprise Architecture and SOA design efforts within the context of the same project or program. At TEC, we have that experience. We understand that EA and EA related governance provide the foundation for all SOA Governance and design considerations – more than that we realize that both of those elements rest upon a shared semantic foundation. Making SOA Actionable requires step by step coordination with the rest of the enterprise. The best place to start is with the enterprise perspective provided by an EA.

What are EA Frameworks? While there are many interpretations of what constitutes EA, most practitioners tend to utilize formal frameworks. An EA framework is essentially a notation + metamodel paradigm used to help build characterizations of organizations. The most common frameworks used today are:

Zachman

Federal Enterprise Architecture (FEA)

Department of Defense Architecture Framework (DoDAF)

ToGAF

UML (as part of something like RUP)

Agile Modeling (a scaled back approach to UML)

MODAF (European equivalent to DoDAF)

IDEF & C4ISR (predecessors to DoDAF)

ITIL (in many ways, ITIL does fit here)

Mapping SOA to EA Frameworks This diagram illustrates an example of mapping several EA’s to an implementation or solution architecture. SOA solutions do not exist in a vacuum, for real value to be realized – synergy is required…

Getting Started with SOA Design At TEC, we begin every SOA engagement with a strategy session to ensure that the scope of the implementation is fully understood in the proper context. Most SOA initiatives represent major strategic initiatives for the organizations sponsoring them, so our initial brainstorming sessions include organizational strategies as well tactical implementation planning…

Agile Design & SOA What is Agile? Agile is not merely Fast, Agile Modeling and project management is methodological philosophy focused on achieving actionable results within predictable, rapid timeframes. Agile Modeling in either application design or SOA implementation support represents the ability to quickly visualize issues and correlate existing models / architectures. While it involves analysis it is not an analytical task – it is used to facilitate rapid decision making and risk mitigation. At TEC , Agile Modeling is an important part of our design process. It allows us to kick-start deployment efforts without sacrificing necessary planning.

SOA is more than SOA One of the key differences that TEC provides as a SOA solutions provider, is the ability to fit SOA within the larger enterprise. We have twenty years of experience with complex data integration solutions. We are also partnered with industry-leading vendors of SOA and SOA-related COTS toolsets and delivery stacks. This solution synergy greater improves the odds for SOA implementation success.

SOA Solution Synergy

Practical SOA Design Principles

Determination of programming language support and exploitation needs to occur at the start.

The COTS you choose Do influence design.

SOA without data layer design is nearly always, incomplete.

ESB deployment and configuration by itself does not represent a SOA data architecture.

SOA can include Software As A Service (SAAS) and vice versa.

Service granularity decisions are extremely important and will effect long-term viability of the solution.

If you did your EA right, much of that information can be leveraged in the SOA implementation design.

Don’t forget performance…

Before exploring more sophisticated design considerations such as patterns or management of orchestration we need to address some common sense issues first:

SOA Design-Time Strategies SOA solutions (stacks) are generally divided between design-time and run-time elements. The Design-Time part of the solution often has it’s own governance solution. The reason for this is that the true benefits of SOA can’t be realized without an effective way to manage the development process. Coordinating SDLCs within or across larger global organizations can be one of the most daunting tasks for any SOA Initiative. There are a number of things to keep in mind:

SOA development usually implies both software development and technical integration.

Programmatic integration needs to occur as well, especially if the domains contributing service logic to the solution are distributed across multiple (semi) autonomous organizations.

This is a governance issue but not one that can be solved entirely with the Design-Time COTs support.

Who Does SOA Design? Who does the work is often as important as what is done. Our SOA efforts are specialized by phase and differ from client to client. The example at left represents a larger project.

Run-time Strategies The most important thing to keep in mind with SOA Run-Time is solution performance. Most of the major SOA stack vendors offer a combination of Service Registry and Repository tools to help manage both service delivery and Run-Time Governance. Not all of these tools are the same, though and there are radical differences in capability depending upon which Stack you choose. Some things to keep in mind here include:

Finding a service is not the most important run-time consideration. WSDL is the most fundamental component of most registries, however the first generation of run-time solutions and related implementations are not terribly sophisticated in regards to how discovery is managed. That is changing though…

The true run-time environment extends well beyond the registry and repository and can even include XML accelerator appliances…

SOA in Context SOA Design considerations must take into account the full enterprise scope…

Future - SOA Design & Semantics The future of SOA Design is closely tied to the emergence of Semantic Technologies…

SOA Patterns More than 100 SOA patterns are now widely recognized by industry. These patterns represent the next generation of pattern exploitation for both Object Oriented Design (OOD) and middleware (EAI) solutions practices. As the use of these patterns matures, more of them will become available ‘out of the box’ in many vendor toolsets. Understanding both the near-term application and long-term management of these patterns will be extremely important for nearly every SOA implementation effort. Examples of these patterns include:

Canonical Protocol

Contract Centralization

Decomposed Capability

Decoupled Contract

Enterprise Inventory

Legacy Wrapper

Logic Centralization

SOA Infrastructure Design SOA Design must be mapped to infrastructure deployment in order to succeed…

SOA Design is Often Subjective There is still a wide variety of opinions regarding exactly what SOA Design practices are in fact Best Practices. To date, the best criteria for making those decisions is often locally determined with stakeholders.

Teksouth Contact Information Thank You… For more information, contact: Stephen Lahanas (TEC partner) [email_address] Or Ken Craig [email_address] (937) 554-4673 (800) 842-1470 (toll free) (205) 631-1500