In the early days Service-Oriented Architecture (SOA) we were told that SOA was not Just a Bunch of Web Services (JBOWS). In a similar vein I would like to suggest that in order to build an SOA you need more than Just a Bunch of Developers (JBODS); you need an Enterprise Architecture. I'm assuming of course that you have a medium to large enterprise to work with. Small companies will be able to get a way with a single, highly cohesive and agile SOA team, but this does not scale well.
So what do I mean by Enterprise Architecture?
"The Only Constant In Life Is Change."
- Heraclitus
For a corporation to be successful it must adapt to changing business markets and technological landscapes. Managing change is crucial to the corporation’s ability to maintain its long-term market agility.
Systems that are allowed to evolve in an unmanaged manner tend towards disorder and chaos and ultimately the inability to adapt.
Enterprise Architecture is the discipline of ensuring that architectures grow strategically, in line with industry best practices and thus remain able to cope with change
Enterprise architecture is defined as the way a corporation is structured, typically defined in terms of:
- Business Architecture:- the business processes and organisations and support organisations that make up the corporation
- Information Systems Architecture:- the systems that support the business architecture
- Technology Architecture:- the infrastructure that supports the system architecture
Architecture evolves over time, primarily in response to the changing requirements of the business, changes in underlying technology, or organisational changes such as corporate mergers. Change needs to be managed, or else architectures will become chaotic and brittle, i.e. costly to change and unresponsive to ongoing business demands.
A simple but helpful analogy: maintaining architecture is like servicing a car. You don’t have to do it regularly, and could save money short term by not doing so, but the long term consequences could be dire. Architectures, like cars, required continual servicing in order to continue running well.
Managing architectural change requires an architecture framework or methodology (such as TOGAF or Zachman) that provides a comprehensive approach for designing, planning, implementation, and governance of enterprise architecture.
It should:
- contain a set of tools to support the methodology
- provide a common vocabulary
- include a list of recommended standards, guidelines and compliant products to guide architectural change
The diagram below illustrates the TOGAF view of managing the architectural lifecycle:
- Agree the architecture framework and guiding principles
- Define the architecture vision in the context of the requirements for business, information systems and technology architectures
- Elaborate the vision in terms of well-defined standards and guidelines
- Look for project opportunities and solutions to help migrate from the current (as-is) architecture towards the architecture vision
- Apply governance with respect to the defined standards and guidelines to ensure projects are aligned with the vision
- Refine the architecture vision as required
- Go to 2
This may all sound like a bit of a mouthful, but the principles are simple:
- Understand where you are
- Understand where you want to get to (in business, application and technology terms), and define this explictly in terms of guiding principles
- Govern your projects against this backdrop.
If you're still finding this difficult to get your head around, you could always offer me a six figure salary and I'll sort it out for you. :)