6 years, 3 months ago

SOA Enable Technology Neutral

by Mike “MO” Oliver, SOACA
Service Oriented Architecture (SOA) is often the chosen Enterprise Technology Architecture for
Integration

It can bring agility in choosing implementation technologies.

Another SOA Guiding Principle  

Photo from Web
SOA can be realized through a variety of technologies and standards. Just like you cannot buy SOA through a product or technology, or use an Enterprise Service Bus (ESB) and get SOA, you can have a SOA using many different technologies.

SOA can be realized through a variety of products and standards, like ESBs from IBM, Mule or JBoss, or even technologies like Enterprise Application Integration middleware or even Spring Integration.  You can balance it between two vendors, and all of them included in your SOA design and implementation.  SOA is really technology neutral.

One of my clients has Integration Bus, another has Mule, another has JBoss, one has all three with each performing a task that is well suited to that technology.  You can use HTTP for transport, or JMS for transport, or MQ for transport or a mix.  Service Oriented Solutions can therefore be built using just about any technologies and standards that are suitable for distributed computing.


Here are some examples:
One of my clients uses Spring Integration for their SOA Implementation.  The key is that they use a Standardized Service Contract and Canonical Schema design patterns to achieve their SOA without an ESB. The Spring Integration services were therefore reusable and composable.

Another client used Message Broker and they did the same thing, they standardized on MQ Transport and SOAP messages with a canonical payload schema. The used Websphere Service Registry and Repository for the Official Endpoint pattern.

Another used a combination of IBM Integration Bus ESB and JBoss Fuse and JBoss Data Virtualization with a JMS Transport.

So to reiterate, you can use a variety of products, technologies and standards to implement your SOA Design.



Talk to Us.

© Sinag Solutions

Unit 903, Antel Global Corporate Center, Julia Vargas Ave, 
Ortigas Center, Pasig City, Philippines, 1605

Office: (632) 956 5175

6 years, 4 months ago

EA = Enterprise Agility

Enterprise Architecture equals Enterprise Agility
by Mike “MO” Oliver, SOACA
Arhicecture word cloud.png

So how does Enterprise Architecture translate into equaling Enterprise Agility, other than the acronyms both being EA?

Standardization

One key element of any quality Enterprise Architecture is the setting and governing standards across the enterprise.  If you have standards on how to do this or that, then you will likely have templates for various code elements or perhaps you have standardized on a Framework or Enterprise Service Bus.  All of these will reduce the training time, design time, and development and testing time to build a solution or service.  Saving time in going from concept to production is by definition improving agility.

Service Oriented Architecture (SOA)

Enterprises that adopt SOA for their strategic integration approach do so largely because of the efficiency  and productivity gains a Service Oriented Architecture can bring. SOA and the Microservices subset are all about designing solutions around small service components that follow separation of concerns and loose coupling paradigms, which also translate into better agility through more granular design and reusable services.  If 50% of the services your current solutions use are reusable, then building a new solution will take much less effort and time, giving you better agility.

Business Architecture

Following TOGAF and documenting your Business Architecture may not seem like it helps translate into Agility, but look at it this way.  If you do not have your Business Architecture documented fully, then as problems and opportunities arise (and they will), how do you know for sure that you don’t already have something in place to do the job? Or worse how do you know what the gap analysis is from what you have to what you need?  That takes time and if you make a mistake and miss something, then you may spend even more time and money to get it right later.  This all translates into Agility.

Conclusion

Agility essentially comes from two things:

  1. Knowledge that keeps you from making mistakes that lead to wasted time and effort.  Enterprise Architecture is mostly about organizing what you have so you know what you have and what you need, and that knowledge makes your enterprise more agile.

  2. The basic Engineering Principle, DRY for Don’t Repeat Yourself.  SOA, as part of your Enterprise Architecture, puts a priority on reuse, separation of concerns and loose coupling. Do those things and you will avoid duplication of effort which equals agility.


© Sinag Solutions

Unit 903, Antel Global Corporate Center, Julia Vargas Ave, 
Ortigas Center, Pasig City, Philippines, 1605

Office: (632) 956 5175