ServiceTechMag.com > Issue L: May 2011

Issue L, May 2011

Mapping Service-Orientation to TOGAF 9 - Part I:
Methodology, Processes, Steps, Principles

Filippos Santas

Filippos Santas

SOA delivery projects contain stages found in traditional IT projects such as Service Design, Implementation and Testing, but also introduce new processes and stages, such as Service Inventory Analysis and Service Discovery within an Enterprise or Domain Service Inventory. Service Orientation [MSOAM] is a prescriptive vendor independent methodology for (a) delivering services as enterprise assets in a service inventory and (b) developing and governing the service inventory architecture in the enterprise, or in a set of domains of the enterprise. Item (b) corresponds to Enterprise Architecture. The Open Group Architecture Framework (TOGAF) is a popular, vendor independent, generic Enterprise Architecture Framework, for developing architectures to meet different business needs. It is developed and evolved by members of The Open Group Architecture Forum. TOGAF is descriptive but not prescriptive, and can be tailored to be used together with other architecture and project frameworks and methods. TOGAF 9 extends previous versions of TOGAF dramatically, but for the purposes of this document we concentrate in the support for SOA as an Architecture Style. TOGAF 9 provides a set of Guidelines on how to use a subset...


SOA Success is Not a Matter of Luck

Prasad Jayakumar

Prasad Jayakumar

World-renowned SOA expert Thomas Erl had stated the following on Service Reusability, "A service capability can be reused in two different ways. It can be repeatedly invoked by the same service consumer program automating the same business task or it can be invoked by different service consumers automating different business tasks ". Based on this thought, services are generally classified into Shared Services and Internal Services. Shared Services [Multiple-Purpose Programs] are true enterprise resources with agnostic functional contexts. They cater to larger group of service consumers. Examples are services which are defined at Enterprise level or Inter-portfolio level. Internal Services [Single-Purpose Programs] have specific functional context. They serve with limited scope to a known service consumer. Examples are services which are limited to Intra-application or Inter-applications within a portfolio. SOA governance board should identify the category to which service/service candidate belongs. There are many instances where a service candidate is identified by a business unit for a specific requirement. This service is termed as internal service, but the scope could be broader. Once a service is properly tagged, the governance board should evaluate shared services as well as internal services. If the board doesn't do so, the pitfall of the existing service will not be known until a problem occurs. This would then leads to a delay while they amend the existing service (non-backward compatible changes) or ...


The Integration Between EAI and SOA - Part II

Jose Luiz Berg

Jose Luiz Berg

As previously stated, the data model in EAI deserves a separate chapter. A common mistake in systems integration is to transfer their job is requirements as the systems communicate. It is common to hear from integration teams, "they are only the pipe, and don't care about what's going on inside it". In fact, the integration concerns the exchange of information (represented by your data) between systems. This is your goal and that is what adds value to the business. This is only possible through communication, but if the information exchanged are incorrect, or simply arrive at the wrong time, they will be worth nothing to your business. Therefore, an old diskette sent by regular mail with the correct information recorded and delivered at the right time is worth more than the most complex Web service, running at best SOA suite on the market, but that has the wrong information. Defining the format and content of the data bus is important because handling this data is the objective of any integration. However, defining a data model for the bus is a difficult task because they should be attached to the definition that each entity has to business processes. To create this model, we must first understand and document the business process, which is a time-consuming and complex task involving interactions with the various areas of the company. This also implies that the areas need to be familiar with their business processes, which unfortunately is not usual. Moving forward, this bus data model will be named ...


2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006