Challenge #1: Can I have an SOA for Xmas
It is important that there is an understanding that SOA is a design paradigm, not a product. SOA is not about just using web services and it is far more than merely integrating systems. It’s crucial to recognise that simply buying more technology won’t solve your business problems. If resolving a business problem was as simple as buying more technology then there wouldn’t be a need for Enterprise Architects. For any enterprise scale SOA initiative this means initially pushing technology into the background. You need to focus your efforts on understanding the business strategy, the business operating model, a business’ core capabilities and its concerns and issues.
Challenge #2: Eating the elephant
“Ambitious, large scale SOA projects will fail unless they’re preceded by smaller projects that establish understanding, policies and best practices for SOA development” ( Gartner, 2007).
How do you get an Enterprise SOA initiative off the ground? The answer is simple in principal:
- Find a stakeholder who is willing to underwrite your early efforts;
- start small;
- keep the initial spend as low as possible;
- reuse as much as possible; and
- gradually build both experience and trust with your stakeholders by showing how you can solve some of their most pressing issues.
Following these steps was crucial to establishing early success and gaining the ongoing support from senior management in ICT, finance and the business.
Challenge #3: The Goldilocks challenge
The title says it all; it’s about the key ingredients being ‘just right’. Taking full advantage of the Gartner recommendation is about doing three things:
Time box the effort and spend. What a reasonable timeframe is in your organization may differ, but I’ve found through experience that two to three months is often acceptable to the people funding these early efforts.
- The business problem
The business problem must be a sufficient pain point for your business stakeholder, so that they will pay attention when you show them how you can solve it.
Talk to your stakeholders about what you’ve achieved in a language they can understand. We undermine our own efforts when we fail to use language that non-ICT people understand. Using analogies is a great way of translating ICT concepts into everyday terms. The analogies don’t need to be perfect; they just need to convey the idea to your business stakeholders.
Challenge #4: Playing by the book
How do you remain agile, make rapid progress and maintain alignment between your architecture and the services you are building without engaging a Big Upfront Design (BUFD) effort?
We found success by following the principle of making architecture a ‘non decision’. This doesn’t mean dispensing with architecture, it is quite the opposite. This means putting in place enough architectural structure that your team can concentrate on solving the problem, not designing the architecture. The key is to establish an architectural baseline by reusing or adopting appropriate reference architectures, frameworks, architectural principles, styles and patterns, along with establishing compatible technology standards. Alongside this there is a real need for the architect to stay closely involved in the initiative. There are lots of opportunities for miscommunication of design intent and direction even when you invest in traditional approaches like BUFD. One of the keys of agile development is understanding that communication is fundamental to success.
Challenge #5: The Good, the Bad and the Ugly
It is important to recognise that there are both benefits and costs associated with change. Significant technology change, at the level of an enterprise or even single business unit, is more than just delivering a new set of tools. Along with the new tools comes a set of new work practises and knowledge to take advantage of them. If a business wants to benefit from the advantages of modern technology it’s got to be prepared to change. This often means changes in governance, in the way technology change is funded, and sometimes in the relationship between ICT and the rest of the business. Service Orientation as an enterprise strategy is a great example of a strategy that demands these types of changes.
"Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.”
Finally, as a general piece of advice to any aspiring Enterprise Architect (EA), you can’t ignore the insight provided by Conway’s Law. The greatest challenge for an EA, isn’t the technology, it is understanding the sociology of the organisation that you are in and aligning the strategy to the organisation’s social, technology and economic drivers. Anything less will meet resistance and ultimately fail to deliver the promised outcomes.
- Service-Oriented Architecture Concepts, Technology, and Design
- SOA Design Patterns
- Enterprise Architecture as Strategy: Creating a foundation for Business Execution
- Enabling Incremental Iterative Development at Scale: Quality Attribute Refinement and Allocation in Practice
- How Much Up-Front? A Grounded Theory of Agile Architecture. Michael Waterman, James Noble and George Allan.
- The Agile Architecture revolution, Jason Bloomberg
 Applied SOA: Transforming Fundamental Principles into Best Practices. Gartner, 2007