A: Did you hear it? Shai said "ESA = SOA + ES".
B: "So what? What's the big deal about SOA anyway"?
(note: if any of the acronyms sounds strange to you, refer to the ESA glossary.)
Have you heard this sort of chats at SAP gatherings? Well, I didn't really hear it, but it simply came into my mind today while I was reading an article which led me to realize that a good explanation about SOA especially from technical point of view would help us elaborate the ESA story since many developers are still trying hard to understand why we should care about SOA and ES in the first place.
ESA = SOA + ES
The first line of the above "play" is from Shai. In September 21, in his TechED'05 Vienna key notes, Shai gave out this equation:
"ESA = SOA + ES". I like it, concise and to the point. It makes it very clear that:
"SOA is for business computing"
The second line of the above "play" is the title of a devx.com article published in September 23, 2005, by Miko Matsumura, the chair of the OASIS SOA Adoption Blueprints Technical Committee.
As Miko noted in his article, there are hundreds of SOA articles out there. Why should I care about YASA - Yet another SOA article? Well, Miko made a few very good points which makes his article a good footnote for Shai's equation.
"Decomposing software into appropriate granular services is an art", Miko acknowledged.
Not everybody can master that art. It takes a lot experiences and expertise to understand business process and identify the "right" services. SAP has developed a pragmatic methodology for discovering services and has provided a preview system for its Enterprise Services Inventory.
In short, ESA is a blueprint, and a successful ESA implementation must have at least two pillars:
B: "So what? What's the big deal about SOA anyway"?
(note: if any of the acronyms sounds strange to you, refer to the ESA glossary.)
Have you heard this sort of chats at SAP gatherings? Well, I didn't really hear it, but it simply came into my mind today while I was reading an article which led me to realize that a good explanation about SOA especially from technical point of view would help us elaborate the ESA story since many developers are still trying hard to understand why we should care about SOA and ES in the first place.
ESA = SOA + ES
The first line of the above "play" is from Shai. In September 21, in his TechED'05 Vienna key notes, Shai gave out this equation:
"ESA = SOA + ES". I like it, concise and to the point. It makes it very clear that:
- ESA is building on top of SOA
- the core value of ESA is the business context that no others understand better than SAP.
"SOA is for business computing"
The second line of the above "play" is the title of a devx.com article published in September 23, 2005, by Miko Matsumura, the chair of the OASIS SOA Adoption Blueprints Technical Committee.
As Miko noted in his article, there are hundreds of SOA articles out there. Why should I care about YASA - Yet another SOA article? Well, Miko made a few very good points which makes his article a good footnote for Shai's equation.
- SOA is nothing new, but Web services are.
SOA is simply an architectural style that can be implemented using any technology. In that sense, "SOA is a pretty old hat". What make it new is when it is implemented using standard-based Web Services technologies. - SOA is designed to make business computing better
SOA is not a panacea for all computing problem. If you are concerned about game programming, graphics, mathematics, and statistical modeling, SOA is most likely not a good solution for you. "SOA is designed to make business computing better".
"Decomposing software into appropriate granular services is an art", Miko acknowledged.
Not everybody can master that art. It takes a lot experiences and expertise to understand business process and identify the "right" services. SAP has developed a pragmatic methodology for discovering services and has provided a preview system for its Enterprise Services Inventory.
In short, ESA is a blueprint, and a successful ESA implementation must have at least two pillars:
- A pool of enterprise services that address common business pain points
- A web services based SOA platform which provides all the plumbing for services enablement and business process management.
3 Comments
