You have indicated that you would be most interested in the Solution Architect Boot Camp.  If this is a new field for you, you may wish to preceed this with the Information Architect Boot Camp, the fundamentals course.

If not security, probably the hottest topic in IT Architecture today is Services Oriented Architecture or SOA. I’ve actually heard some folks say “We’re not getting trapped in the buzz around Enterprise Architecture – we’re doing Services Oriented Architecture”. No kidding – I heard this at a computer organization dinner this week, and yes, the comment was made by a manager, not a “techie”.

This article will focus on the need to include SOA within your EA.

SOA – A Major Building Block in Enterprise Architecture

Service Oriented Architecture is not meant as a new way to define Enterprise Architecture, but it definitely needs to be a major focus of both the application architecture and technology architectures.

When building our Enterprise Architectures, many organization fall into the trap of believing that they need to create models, principles, guidelines and standards on every part of their environment. This is usually why it is never completed, the projects are shelved and budgets run dry.

Successful organizations create strategies to build their Enterprise Architectures in an iterative manner, focusing on the framework and basic components first, and then moving on to add critical models and detail sections of the architectures piece by piece as IT initiatives dictate.

SOA should be viewed as a “sub-architecture” of the Enterprise Architecture, one which should be a primary and early focus. Many organizations will have components of architecture for connection and messaging capabitilities needed for SOA. These should be heavily documented in great detail, and the EA strategy should include a communication strategy that shouts from the rooftops that this architecture is available and ready for prime-time. Development teams should consider this architecture first when deciding on methods for their current projects.

SOA using web services will allow us to support today’s flexible needs of business. Our architectures should include, whether bought or assembled, most of the services we will need for our Enterprise Architecture. As new business initiative arise, we add value by reusing existing services that we have proven to be effective, and building or developing new services that give our organizations some type of competitive edge or fill our unique business needs.

Our enterprise archiecture, built within the confines of one or a few selected methodologies and framework will include views, abstractions and models. The basic components of the SOA infrastructure are paramount to our successes and must be modeled in detail in order for us to encourage the use of and support applications that will be built to give our business departments the edge.

Information and organizational technology requirements don’t really differ much between organizations. We all need customer, contact, accounting, financial, purchasing, human resources, and security solutions, just to name a few. Services and components will eventually be available to meet all of these needs in a variety of ways. We need to architect our systems and environments in such a way that we will be able to use these generic types of point solutions.

The uniqueness or competitive needs of our organizations and our business architectures will beg us to use solutions such as SOA to focus on the development needed, rather than the plumbing. We’ve all heard SOA is the next silver bullet, but there is work involved in accepting and including it in our architectures. The next models you build should embrace these thoughts and models, components and services to support this direction should be high up on your “to-do” list of models to be built.

A few notes regarding the maturity of Service Oriented Architecture are worth recording. An area worth discussing is our efforts to carefully plan and design our systems to insulate us from the impact that comes from our business rule changes.

Most maintenance comes from either technology upgrade or business change, hence the need for heightened attention in planning these areas of our system designs and application frameworks. While SOA is the hot topic of the day, it is the “how” that we must carefully watch. Technology and methodology choices will either assist or expose us to volatility in the future.

Languages such as BPEL (Business Process Execution Language for Web Services, should be reviewed and contemplated for use in our designs. It aides us in taking a top-down process approach to SOA. As we prescribed earlier, top down design taking a business rule perspective will be critical in embracing this paradigm shift.

Service Oriented Architecture is ALWAYS business driven, and before we start, we must consider our plan of attack with respect to architecting in the ability to absorb business rule changes.

Solution Architecture Quality Checklist