Keynote from EA Practitioners: SOA and EA – in the real world

David Linthicum of Zapthink is speaking.
Conference materials live at

David Linthicum wrote, “Enterprise Application Integration”

Dysfunctional architectures that are currently deployed have led to enterprise that are locked up and unable to really improve because of the complexity. The activities ahave all be driven by tactical needs not strategic needs.

Enterprise Architecture are raising their hands and saying we need a “master city plan” but they don’t get the budgets or support so they end up acting tactically also.

Need to convince people that the SOA technology and strategic planning are important. Need to start with the business case. The business drivers: Reduction of integration expense, increase in reuse, greater visibility, business empowerment and increase in business agility.

“Think big, start small, succeed often”.

Building support:

Need to find a champion, a LOB manager, CIO, management-level architect or other architect.
Need to build the business case and show ROI though the calculation can be difficult because there is no historical data (SOA implementations), it is difficult to differentiate between a well-architected SOA vs. non-SOA architecture and what do you gain from agility.

We are trying to decompose the enterprise into functional primitive behaviors that we can then re-orchistrate as we need to. We don’t do code level re-use, that has never work. We deal with behaviors that are put behind a neutral dial-tone that lots of different technologies can take advantage of.

Business Intelligence: Visibility into data, business processes and into levels of compliance. Once we have these services that are communicating outside of their technology stack, then we can peer into the interactions and information. We can then deliver that information in any number of ways: a spreadsheet, a dashboard on a blackberry. This is “sex-in-the-screen kind of stuff” the C-levels love.

Agility: Need to identify the need for agility for the business itself.

When not to apply SOA: when business requirements are stable, when the IT environment is homogeneous, when current tools provide sufficient visibility, when performance requirements call for efficiency over flexibility. Don’t be led by VDA – Vendor Driven Architecture.

JBOWS – Just a Bunch Of Web Services – nothing is solved when all you do is build a bunch of web services. Service enabling is not where you gain from SOA. It is the consumption and re-use where the gains come. You must design for re-use.

Start with the business requirements and architectural planning, then back the technology into the problem domain. You cannot buy SOA, it is something you do not something you buy. If you buy and ESB and a bolt it onto the enterprise, you will just make things worse. Note that governance and security are systemic as is performance engineering.

Architecture should be: implementation-independent so that is it stable as technology changes, business process-indpendent so it stays stable as business changes.

Technorati Tags: , , , , , ,