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”.

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”.

The TEC Methodology – “i-TEC”

Introduction – What is SOA? “ Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the overall burden of IT on an organization .” www.soaglossary.com Services Oriented Architecture (SOA) as a philosophy and a practice is still maturing. However, customer expectations for leveraging SOA as a facilitating design strategy to achieve enterprise integration often exceeds industry capability to meet those expectations. While many regard SOA as merely an architecture or a design philosophy, customers signing up for it don’t see it that way. SOA as a Practice Must Have predictable and measurable results.

Services Oriented Architecture (SOA) as a philosophy and a practice is still maturing. However, customer expectations for leveraging SOA as a facilitating design strategy to achieve enterprise integration often exceeds industry capability to meet those expectations.

While many regard SOA as merely an architecture or a design philosophy, customers signing up for it don’t see it that way. SOA as a Practice Must Have predictable and measurable results.

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 .

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 .

Elements of 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.

Enterprise Architecture, Solution Architecture & Solution Design

Lifecycle Management & Governance

Infrastructure

Integration

Legacy Transition

SOA - The Basics SOA is largely associated with the Web Service stack of standards. While use of web services is not required to be considered SOA, it is certainly expected. The core premise behind this stack of standards is the ability to distribute and discover capability easily.

Key SOA Definitions The Service Provider who publishes available services and offers bindings for services. (Data Access) The Service Broker who allows the service provider to publish services (register and categorize). Brokers also provide mechanisms to locate services and providers. (Data Discovery) The Service Requestor who uses the service broker to find a service and then invokes (or binds) the service offered by a service provider. (Data Consumption) The Service Inventory represents the set of domain or enterprise services available for discovery or composition. Service Composition & Orchestration refers to the ability to aggregate capability by combining existing services.

Example Service Inventory View

Understanding SOA Standards SOA-related standards are still confusing: Because there are quite a number of them. Because they are not fully mature. Because the boundaries of what constitutes a SOA solution are still nebulous and evolving. Because it is not always clear which standards apply to specific implementation scenarios. Because interoperability between vendor SOA platforms is sometimes interpreted differently. Because sometimes best practices or design principles are interpreted as standards. As noted earlier, the core web service standards still provide the ‘standards’ foundation across most SOA solutions and platforms. Interoperability between SOA solutions must focus on a relatively small subset of ‘universal’ standards to avoid additional integration.

SOA-related standards are still confusing:

Because there are quite a number of them.

Because they are not fully mature.

Because the boundaries of what constitutes a SOA solution are still nebulous and evolving.

Because it is not always clear which standards apply to specific implementation scenarios.

Because interoperability between vendor SOA platforms is sometimes interpreted differently.

Because sometimes best practices or design principles are interpreted as standards.

Enterprise Integration Principles

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:

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

The SOA Paradigm Shift How does one decouple the n tier layers of a single system that supports more than 100 functions, 100 data elements, several dozen accepted process flows and dozens of unique reporting formats? Furthermore, how are the parts of the decoupled layers developed and managed – who does what now. The enterprise expectations for how UI, process and data should be handled in most cases will be radically different than any one vendor / developer’s perspective. This also extends to conventions for service design as well and coordination of service logic with the other decoupled layers. So, the system has now been decoupled, but wait, that only solves the old problem – we now have a new more sophisticated problem to solve. This is the true SOA paradigm shift…

How does one decouple the n tier layers of a single system that supports more than 100 functions, 100 data elements, several dozen accepted process flows and dozens of unique reporting formats?

Furthermore, how are the parts of the decoupled layers developed and managed – who does what now. The enterprise expectations for how UI, process and data should be handled in most cases will be radically different than any one vendor / developer’s perspective.

This also extends to conventions for service design as well and coordination of service logic with the other decoupled layers.

So, the system has now been decoupled, but wait, that only solves the old problem – we now have a new more sophisticated problem to solve. This is the true SOA paradigm shift…

From System to Services…

SOA is Evolution, Not Revolution Contrary to some popular wisdom surrounding SOA, we are not in fact reinventing the wheel. What we’ve learned to do in relation to enterprise integration does not go out the window to suit SOA 101 perspectives of our new enabling techniques. Data layer architecture and engineering in particular have grown much more sophisticated over the past 20 years and SOA has not yet developed a best practice approach for merging with sophisticated data layer solutions. Service coding as well needs to be considered, OOD techniques that led to SOA are in fact being ignored in regards to core issues of modularity and manageability of code to suit early design guidance for SOA granularity. That guidance was developed in response to smaller, simpler scenarios…

Contrary to some popular wisdom surrounding SOA, we are not in fact reinventing the wheel.

What we’ve learned to do in relation to enterprise integration does not go out the window to suit SOA 101 perspectives of our new enabling techniques.

Data layer architecture and engineering in particular have grown much more sophisticated over the past 20 years and SOA has not yet developed a best practice approach for merging with sophisticated data layer solutions.

Service coding as well needs to be considered, OOD techniques that led to SOA are in fact being ignored in regards to core issues of modularity and manageability of code to suit early design guidance for SOA granularity. That guidance was developed in response to smaller, simpler scenarios…

The TEC SOA Practice

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.

Agility

Flexibility

Relevance

Traceability (from inception to retirement)

A Semantic Foundation

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.

TEC SOA Practice – Governance There a quite literally 100’s of interpretations in IT as to what Governance represents and how to achieve it. Within the field of SOA, Governance is occurring within differing sets of vendor tools as well as in a variety of related processes, including: Application (service logic) development Portfolio Management & EVMS Enterprise Architecture & Requirements Acquisition Management Project & Program Management Change & Asset Management One could get easily lost within the ever increasing number of disciplines & toolsets dedicated to ‘Governance.’ We’ve simplified that by collapsing all of this into a single process.

There a quite literally 100’s of interpretations in IT as to what Governance represents and how to achieve it. Within the field of SOA, Governance is occurring within differing sets of vendor tools as well as in a variety of related processes, including:

Application (service logic) development

Portfolio Management & EVMS

Enterprise Architecture & Requirements

Acquisition Management

Project & Program Management

Change & Asset Management

One could get easily lost within the ever increasing number of disciplines & toolsets dedicated to ‘Governance.’ We’ve simplified that by collapsing all of this into a single process.

SOA & Federal Acquisition An example of how unified SOA Governance is applied to the DoD…

TEC SOA Practice – Infrastructure Infrastructure is more than servers that host applications / services or the datacenters that house them, it is the enabling fabric for all IT capability and as such also includes : Security or Information Assurance Telecommunications Networking & Quality of Service End user support Data storage & Archiving Messaging & Collaboration Often in large SOA transformations, Infrastructure is viewed as services, usually being offered first before specific application logic is made available. Actionable SOA always considers infrastructure – designing and building interactively within it.

Infrastructure is more than servers that host applications / services or the datacenters that house them, it is the enabling fabric for all IT capability and as such also includes :

Security or Information Assurance

Telecommunications

Networking & Quality of Service

End user support

Data storage & Archiving

Messaging & Collaboration

Often in large SOA transformations, Infrastructure is viewed as services, usually being offered first before specific application logic is made available. Actionable SOA always considers infrastructure – designing and building interactively within it.

Infrastructure & SOA are Symbiotic While there are many types of SOA projects, they all involve infrastructure. There are many specific infrastructure tasks which must be addressed for a SOA Initiative to succeed.

TEC SOA Practice – Integration Enterprise Integration is generally thought of as a reactive exercise, where IT departments struggle to achieve interoperability through a costly process of building interfaces between solutions that don’t talk to one another. Services Oriented Architecture is in fact the Proactive Alternative to traditional Enterprise Integration. The whole point of SOA is not some esoteric exercise in design - it is to provide integrated IT capability. It does this by establishing a foundation that supports a significant level of integration up front, “out of the box.” To achieve this though, the SOA Initiative must understand and predict integration concerns, dealing with them up front.

Enterprise Integration is generally thought of as a reactive exercise, where IT departments struggle to achieve interoperability through a costly process of building interfaces between solutions that don’t talk to one another.

Services Oriented Architecture is in fact the Proactive Alternative to traditional Enterprise Integration. The whole point of SOA is not some esoteric exercise in design - it is to provide integrated IT capability. It does this by establishing a foundation that supports a significant level of integration up front, “out of the box.”

To achieve this though, the SOA Initiative must understand and predict integration concerns, dealing with them up front.

Integration & Integrated Capability These two are not always the same, that’s the main thing that SOA is dedicated to correcting. Integration outside of the holistic enterprise perspective is costly and ultimately unsuccessful.

TEC SOA Practice – Legacy Migration There will always be Legacy IT capability. What is or isn’t Legacy capability will be somewhat subjective depending upon the relative maturity of the enterprise in question. Understanding how to transition from Legacy capability to a fully modern SOA foundation is perhaps the single greatest concern in any implementation. Over-analysis of existing capability is just as bad as no analysis at all. The transition effort must be agile in order to support rollout of new services-based capability. There are also opportunities for reuse and legacy exploitation which must be considered.

There will always be Legacy IT capability.

What is or isn’t Legacy capability will be somewhat subjective depending upon the relative maturity of the enterprise in question.

Understanding how to transition from Legacy capability to a fully modern SOA foundation is perhaps the single greatest concern in any implementation.

Over-analysis of existing capability is just as bad as no analysis at all. The transition effort must be agile in order to support rollout of new services-based capability. There are also opportunities for reuse and legacy exploitation which must be considered.

The TEC Understands IT Transition

The SOA Semantic Foundation Semantic Fabric All aspects of any IT infrastructure share a common semantic fabric. This semantic fabric allows to merge SOA logic & business with data. Occurs when that fabric is managed

Putting it All Together – SOA Done Right Actionable SOA or SOA done right is implementable SOA – no excuses. It’s the ability to leverage decades of existing knowledge and apply new technologies and techniques to get the job done right, the first time.

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