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.

All I needed to know about SOA I learned in Kindergarten…

If this term is new to you, or you want a different spin, it’s time everyone in IT Architecture should know at least a little about SOA – Service Oriented Architecture. SOA (service-oriented architecture) has become a buzzword in Read the rest…

More fun and adventures with SOA. This week I was explaining to one of my customers that the models we were designing needed to include very “generic” pieces so that we could have the developers and designers implement them as services. We discussed it at length and finally the light bulb went on.

It was fabulous to see the look on her face when I explained that there had been many talks to integrate with such a service, and since the decision had been not to, it was not lost. You see, there were business implications in integrating the service, and while the business did not dismiss the objective as impossible, they said “just not right now”.

We have to include design for such possibilities, even if we don’t have all the plumbing installed at the time.

It’s an exciting time in both Enterprise Architecture and IT architecture in general, as SOA continues to build momentum and gain respect as more than a silver bullet.

I cover the topic Service Oriented Architecture extensively in both the Enterprise Architecture Boot Camp, as well as an upcoming one day workshop “The Service Oriented Architecture Boot Camp”. For more information, see the training catalogue.

Give the Business What They Want!

Last week as I was shuffling my IT magazine pile looking for something good to read, I came across an editor’s note in EDGE Magazine that validated something that I’d worked on very recently. As enterprise architect’s, we are always trying to be validated, justify our projects and sustain funding for the next wave of what we hope to be the path to goodness.

The article stated “Ask any CEO to name the very top items on their agenda and the conversation invariably turns to “innovation” and “transformation”. As any CIO to name their very top things on their list and they will tell you its “information” and “technology.” “

Previously I ran a workshop at a PMI conference called “Optimizing the Program Portfolio” that reinforced some of these same beliefs. The crux of it all was that if we were to carefully plan and plot our course of programs with both our assets and proposed projects in mind, we should maximize efficiencies reducing budget and time resources spent on running the business. This in turn, would make more time for transforming the business.

It seems like a simple feat, but this is more complicated than one would think. Program Management and Enterprise Architecture are so very deeply intertwined that one should hardly talk about one without the other. It seems that we never get past choosing a framework, cobbling together a strategy and then completing the first few models and maybe a set of principles. Beyond all of this is planning for transition.

There will be so many projects that need to be planned and executed in order to get an actionable enterprise architecture, that we will likely be overwhelmed and unable to get even the smallest percentage done because of ongoing operational and infrastructure support projects. It is important that we carefully time and plan what will happen next so that in the end we are making more time for the things that CEO’s have on the top of their lists.

Often we do our CEO’s top priority, but at the expense of our operational needs. We are in a rush to bring in silver bullet solutions, excess resources, and cut in-progress projects because they aren’t on the top of the list. Sometimes, we need to push back, ever so slightly on timing only to ensure that the infrastructure and architecture can support these transitional projects.

On the other hand, we need to expedite these projects, and keeping an eye on our top priority has become easier now that we have the attention of most in the organization. Services oriented architecture is most likely not just flavor of the day, and we are apt to find support for infrastructure and architecture projects that will support it.

So where does the portfolio management story fit in? We must take a look at our top three priorities both from an IT perspective as well as a corporate view, and determine the best ordering. We should look at what we have (our assets), leverage them as best we can, and then view our gaps and projects on the books to come up with a portfolio that will make both the CEO and CIO smile.