Useful SOA Bookshelf

Shawn Simon — Wed, 09 Dec 2009 19:47:24 +0000

My Professional Library is speaking out! A listing of print resources new and old, they made it to my top shelf. Some have dropped off the list and new ones added, but all together, this compilation should prove to be very valuable to those of you who still read. However, I don’t believe the Kindle will be of much help with these reference materials – get the real thing. My hope is to one day, provide some short reviews on each with my personal SOA flare, but for now – trust me or lean on Amazon.

SOA Technical

The technical know-how books vital to SOA design and implementation.

The “Erl” Suite
- SOA Design Patterns
- Service-Oriented Architecture: Concepts
- Service-Oriented Architecture: A Field Guide
- SOA Principals of Service Design
- Web Service Contract for SOA
Enterprise SOA: Service-Oriented Architecture Best Practices

SOA Business

The business-savvy books that help illuminate the value proposition.

SOA Governance
The New Language of Business: SOA and Web 2.0
Service-Oriented Architecture Compass
Succeeding with SOA
SOA for Dummies - ok I know, I know, but this book makes at least one solid point early on

SOA Ancillary

Some related material that I have found quite helpful for integration challenges.

Enterprise Master Data Management: An SOA Approach
RESTful Web Services
Continuos Integration: Improving Software Quality
Domain-Driven Design: Tackling Complexity
Pattern Oriented Software Architecture (V1)
97 Things Every Software Architect Should Know

SOA Foundational

SOA is chuck-full of standards. Here are some key groundwork type of material.

SOA is Turning Things Upside Down

Shawn Simon — Wed, 25 Nov 2009 00:23:13 +0000

Enterprise Architecture Frameworks teach us about layers. With the introduction of SOA, should we revisit what we learned? In my recent post about “Layers” and “Patterns”, I was trying to argue the importance of “Services” and their role (as not the only player) in an SOA. With that said, I am being reminded of a diagram I used to see describing Enterprise Architecture Frameworks by decomposing an organization into “Layers”.

Wikipedia currently is showing this image:

I believe the intent was two-fold. (1) Identify specific roles and domains and (2) show respective hierarchy to one another. The latter may be more subtle, but clearly it is important for architects to understand the Business artifacts come first, then the data, then applications, then technology so why not stack them like the diagram suggests. However, I was wondering why the triangle was chosen? By using this representation, it seems to typify another generalization, albeit maybe unintended. The domains on top are smaller then those on the bottom. Was this on purpose?

I am pontificating now, but is this because we think we need to put more effort in terms of output for those with larger area? Is this true and if so why not more outcry from the business? Or maybe we all realize that in practice we see our architectures made up of more from the bottom then the top? If nothing else, even today I see more energy, more conversation, more debate and more specialization in the technology space then any other domain of Enterprise Architecture. Is this age-old symbolization of architecture the genesis of unintended consequences: Technology is King and the business is it’s humble servant? How can that be, the business is at the top right?!? Well maybe better said, Technology is King and the business is it’s diadem.

Consider flipping the triangle. Where not only is the business at the top but also consumes the most area. Then follows data, applications and technology where the bottom is smallest portion of the architecture. I know this would never fly due to experts smarter than I saying, “It all points to technology and thus counterintuitive” or my favorite, “It does not have a flat foundation, how can it stand?” Even so, I believe there is some merit in this new depiction.

With the advent of SOA traction in Enterprise Architecture, it should ideally minimize the importance, effort, and landscape of technology. In a very real sense, technology is merely the interface gateway and maybe infrastructure to the enterprise. The process modeling, data management, decision intelligence, service components should begin to be extracted from the technology space and become more common place in the business domain. BPMN, BPEL, rules engines, process improvement and the like are forcing us to get the business people more involved in architecture – the true allure to an SOA.

And since I am busting down some long-standing doors, why not even change the domains slightly. Why do we even need to bring up Applications anymore? In the past we modeled our business after COTS or IT limitations, so the application domain is where the real business logic resided. This lead to it being recognized as it own domain. Now we realize we should model our architecture, systems, technology after our business. Allow agility to enable technology to meet the individual need. In this sense, the application domain has become a Service Layer. Business oriented services that interact with applications, data or people. I would still agree that the data domain trumps the service domain in both significance and effort thus higher on the diagram. Finally that leaves the business at the top that is most important as well most invested in. The business thus leverages data, services and technology to build the very processes and methodologies that model their goals, motivations, differentiations, etc.