|
Jun 21
2010
|
|
 |
If you’ve been around the enterprise software industry the last few years, no doubt you’ve heard the term “service oriented architecture” (SOA). If you aren’t technical, it’s one of those terms that flies right over your head. That's understandable given the dictionary-sized list of related technical acronyms such as SOAP, XML, CORBA, DCOM, .NET, J2EE, REST, BPEL and WS-CDL.
Software Advice, a website that reviews software systems for manufacturers, recently created a plain english guide to understanding SOA. They propose SOA can be understood through a simple analogy: think of SOA as the information technology (IT) equivalent of managing a large, diverse workforce. To get stuff done in a big organization, you need to:
- carefully define your goals and what constitutes success;
- draw on the unique talents and knowledge of each individual;
- get people to speak the same language and work together as a team; and,
- measure where things stand and whether success is achieved.
SOA does all that for IT. It catalogs what systems are in place and what they can do (e.g. what data they own). It specifies a common language that they can all use to communicate, even if this common language is not each system’s “native tongue.” With those components in place, the organization can build new applications or processes that make use of the multi-system integration. Finally, a SOA coordinates and monitors the processes that span these systems.
To continue reading, visit: Service Oriented Architectures (SOAs): A Plain English Guide
Subscribe to this comment's feed
Show/hide comments
Show/hide comment form
