Enterprise Abstraction

On a simple EA governance process

When we first embarked on the "EA Adventure" we'd received a goodly deal of in-house training and consultation - and we followed up on that with lots of reading and conference attendance.  All of these sources stressed the importance of architecture governance - and we agreed - an architecture that isn't followed or implemented is less than worthless.  However, few of our sources offered any suggestions on how to actually execute that portion of the process. 

We were particularly concerned that our organization is a rather small one - and our architecture group is proportionately diminutive - we wanted to reduce the amount of time spent on governance to a minimum.  Moreover - there was concern that the architecture group itself does not really have any direct decision making authority with regard to projects.

We established what we'd considered a pragmatic process for governing architecture alignment (then called compliance) in projects.  It essentially involved reviewing a project at 1) the planning stage, and during the 2) software design and 3) development stages.  Performing the review would be a committee - the Architecture Review Team - consisting of the architects and various heads within the technology department.  The project manager or technical lead would demonstrate the relevant parts of the project to the committee, and we would evaluate the project's alignment based on our standards, models and principles.  Good right? 

Of dozens of small projects - we successfully completed 2 partial reviews in 3 years - and neither of those reviews were actually successful in creating any sort of positive change in the projects.  So, what were some of the problems?

Firstly - we'd not really established the fact that our efforts should be guided from the very beginning of an initiative -- at the project proposal stage -- by architecture.

Secondly, the section heads that we'd invited to participate in the committee were not particularly well versed in the architecture, or architecture process.  They felt that they could contribute very little to the governance process.  Only the architects - involved in the depth and breadth of the architecture could really have an up-to-date understanding of the architecture to make informed decisions. 

Finally - getting that large group together to perform a review was an exercise in logistics.

Hence, not a terribly successful first attempt.  We couldn't review the projects early - when we could have the most positive impact before a project had already established a scope and plan - and we couldn't perform reviews in a timely fashion - it taking so much time to arrange meetings, review the material and keep up to date on architecture.  Most importantly - we felt we were wasting a lot of time for little impact.

How did we make it work better?  We abolished the malfunctioning Architecture Review Team - and replaced it by having an architect assigned to each project that was responsible from beginning to end in tracking the alignment - from proposal to close.  The architect ideally helps to write or consult on the project proposal and plan - and establishes which architecture components would be implemented by the project (if any), and keep track that the project was meeting established technology standards and architecture principles.

If there is an alignment issue - it's brought first to the technology lead or project manager - either directly or in a team meeting.  Failing a resolution at that level the issue can be reported to the project review committee (a committee that's assigned to oversee individual projects -- to help remove roadblocks and provide guidance).  Failing a resolution of the issue at that level - the problem is presented to the project sponsor and/or the corporate management team.

It's a reasonably nimble process - relying mainly on the resource availability of the architect (easily managed), and taps into the authority already existing in the project management and project portfolio processes already in place.

At this point in our second attempt at architecture governance - things seem to be going well.  We're currently tracking the alignment of at least 50% of the ongoing projects - and likely 100% of the architecturally significant ones.  Recommendations are more easily accepted - and in the few cases where there have been serious issues - they have been resolved reasonably quickly.

I'm crossing my fingers for continued success.

Public Review Draft WS-BPEL 2.0

IT Toolbox reports:

Last Thursday, August 24 the OASIS BPEL Technical Committee published the first Public Review Draft of WS-BPEL 2.0. This is a major milestone that many folks have been awaiting for nearly 3.5 years – since the spec was donated to OASIS.

See the Public Review Draft of WS-BPEL 2.0

Rolling stone of governance

My experience with a large library/small organization is that the best you can do when starting architecture is to get the stone rolling in the right direction, and subsequently, and only if absolutely necessary, nudge it from that point forward.  It's impossible to stop the stone (any particular project or initiative) once it's built up some inertia.

We've tried "after the fact" governance processes that were too heavyweight and too late to be effective, no matter how logical or economical our arguements.  My experience is that unless you start projects on a firm footing, there's very little chance of having anything but a limited impact on success of a project post-initiation.

Hence, we've put most of our effort in providing a service to business of helping them construct their proposals and manage the project initiation process.  In some cases we'll initiate projects ourselves.  In other cases, we'll parachute in to offer a prospective project proposer assistance with scoping, tasking and estimating a project early, and most importantly, with improved speed and efficiency as compared with the more traditional method. 

We find that in our practice this reduces uncertainty and eliminates most of the "investigation" projects spawned from fear of not knowing the complete solution up front.  Most importantly, ideas usually manage to move from thought to proposal stage an order of magnitude faster than they had  otherwise.

The biggest challenge thus far has been to have architecture perceived as primarily an enterprise  project management and business-related process than the common view of it as a technology-related process.  This acceptance has proven to be achievable, but it's taken uncounted weeks and months of communication and demonstration to convey. And still the march goes on.

Transitional Architecture

An interesting article from IEEE's IT Professional journal entitled ENTERPRISE ARCHITECTURE - Transitional Architectures for Enterprise Evolution by Murat Erder and Pierre Pureur.

The article describes transitional architectures, and introduces the idea of change in architecture avoiding the sometimes difficult direct from current to the "to be" architecture leap.  They propose what they call a prescriptive approach using a series of achievable application plateaus and architecture waves that help to ensure the achievement of business value with each transition  towards the to be architecture, and avoiding being in a constant state of transition. 

Basically, a series of architectural rest stops on the path to the final destination.

In this article, we offer our version of the prescriptive approach:  Why not briefly document the current state of the architecture, define the desired state at the conceptual level,and finally define transitional architectures on the way to reaching that goal? In other words, we introduce the idea of change within the architecture process.By following this approach,you will quickly learn which areas you need to focus on before moving forward with the architecture models and blueprints. Our method also yields several important benefits,including a focus on delivering architecture features that matter most to the business; effective risk mitigation, expectation management, and requirements traceability; and lower costs.

The article is very readable, and may be of interest to developers, designers and business analysts as well.

Web service naming convention

A developer recently asked me about standards for naming web services.  I have no idea.  Our architecture standard names components as "verb noun" phrases, so I suggested things like:  "AuthenticateClientService" and "FindDocumentService".  Yes, the "Service" portion does seem redundant, but we're thinking that it will help readily identify it when referenced out of context in future.

Is there any sort of convention for naming web services in the enterprise?

Mr. Malik asked the question awhile back, but that's all I've been able to find, and it seems no answer was provided.  The many examples of WSDL's I've seen lack consistency, and seem to rely on the whim of the creator.

Your suggestions and pointers are requested and welcome.

UPDATE:  I discovered some info on good service/web service naming practices.

Development capacity for improvement

Nick Malik brings up a good point regarding the need to have extra - IT driven - capacity to apply purely to the task of simplifying and reducing the complexity and maintenance of systems.  In my experience, nature abhors a vacuum, and it's particularly difficult to have a full team dedicated to reducing complexity, even if you could justify the expense by having the team pay for itself through reduction of costs.

I think it would be particularly important in the establishment of such a team to ensure that it was driven by it's mandate to reduce complexity, and to ensure savings over the long term.  I agree that it would be best to be IT driven, and not driven (directly) by the ongoing business concerns.

Werner Vogels interview large scale systems

I admit it, I'm a bit of a Vogels fanboy.  I try not to repost Slashdot postings, but I'll make an exception for this ACM QueueCast interview with Werner Vogels, CTO of Amazon.  I like his attitude, and I feel he has some credibility since they're one of the first truly successful SOA implementations around, both internally and externally.

They also have the interview in mp3 format. 

SOA and Agile - Peas in a pod

Brenda posted about the compatibility of SOA and Agile, comparing them to apples and oranges.  I'm not sure of the best metaphor to use, but in my opinion they're undoubtedly compatible methodologies. 

It's human nature to want to 'waterfall' processes.  From architecture to software design and development.  EA, SOA and, of course, Agile, all benefit from an iterative and incremental approach.  Another key practice I've heard applied to both is to, "do just enough, just in time" -- or just in time/agile architecture.

Amongst the strengths of agile methods are the strong assertion that you don't know all the answers up front, that you're willing to accept and embrace change at any point.  These are excellent principles to apply to SOA as well, within reason.  Assuming you're going to start from zero and work out a complete and workable architecture, followed by a representative development and implementation is probably folly. 

Architecture, among other things, is meant to constrain and guide development.  In this regard, EA, SOA and agile should be able to live together harmoniously as long as the architects and developers come to a pragmatic consensus about boundaries and collaboration.  This means having a good working relationship between the two camps, and a good idea of the reasons and methods behind the respective schools of thought.  This, perhaps, is the hardest thing of all to accomplish.  It certainly requires a lot of trust on both sides.

The approach we've taken thus far is to have architecture define a set of well validated services, interactions and general interfaces based on our EA practice, which is directly traceable to business desires.  During implementation we have used an agile methodology to actually construct the innards of the services, integrate, and to build human interfaces and detailed components of the desired system. 

The architects take care to guide the direction, and assert control only over the critical (architecturally relevant) portions.  Usually this means staying at a fairly high level of abstraction. The remainder (the details of implementation, integration, detailed data structures) are left for the designers/developers, and if they choose, an Agile approach.  This works best if the designers/developers and architects will interact as the project proceeds to make adjustments and clarifications as needed.  In this way the architecture, and the implemented system both come closer to meeting the true needs of the business in the end.

I'm keen to hear other opinions in this regard, as admittedly my SOA and Agile experiences are still quite new, and only partially tested in the real world.

SOA middleware and ESB study

The AberdeenGroup is causing quite a stir with its recent study of 120 organizations and their adoption of Enterprise Service Bus (ESB) and SOA middleware technologies.  They claim:

• 90% adoption of SOA technology amongst the surveyed organizations

• 5%/year savings on integration costs amongst those organizations who have adopted SOA

• 40% of IT budgets are being spent on integration expenditures due to business process redesign and customization challenges

Note the 90% adopting SOA technologies.  This is perhaps not exactly the same as saying that 90% have adopted SOA.  The report is about ESB's and SOA middleware technologies specifically.  It's a subtle but important distinction.  Nevertheless, it would seem to imply a huge adoption of these technologies, and that certainly implies something.

They indicate 3 flavours of SOA and SOA suite adoption:

• SOA Lite is for users who are primarily deploying web services that do not require mission-critical capabilities such as high-volume scalability, high availability and failover, management, governance, and security.
• SOA ERP is used by companies that are choosing to deploy SOA surrounding their ERP application software.
• Enterprise SOA requires and uses mission-critical SOA middleware suite capabilities.

(-- from aberdeen.com)

Do enterprises require SOA middleware suites for mission-critical services?  I'm not sure.  There's perhaps something to be said about designing your services and service architecture for the required mission-critical features first, and adopting ESB/Middleware as an ease of adoption feature.  Vogels certainly encouraged this approach, but, not everybody's Amazon.  Having not yet approached SOA adoption from the indicated "Enterprise SOA" level, it's hard for me to say.  Nearly half the organizations in the study were classified in the "SOA Lite" category.

Other tidbits include:

• 1/2 of respondents are using Java J2EE technology in their SOA adoption.
• 1/3 are implementing on both the Java and Microsoft.NET platforms.
• Half of the respondents are considering enterprise application integration (EAI) side-by-side with ESB purchases.
• Average organizations are using  ESBs and SOA technology to reduce IT complexity, the costs of complexity, and to speed IT implementations
• Best in Class (BIC) organizations are driven by the need to align with the business and re-use applications via Web services.

With regard to SOA rollout and ESB adoption generally, the report says:

ESB adoption is a large enterprise phenomenon, with only about 7% of large companies
saying they have no plans to start using an ESB in their SOA rollouts. However, the majority of mid-size organizations and almost 80% of small companies have no plans to use ESBs, yet they are already designing and programming SOA applications. These data indicate that smaller companies are adopting the standards of SOA and the related programming, but are not yet ready to adopt an SOA style of development for missioncritical applications — or they will rely on SOA ERP to close the technology gap.

A full copy of the report is available free (with registration):   Enterprise Service Bus and SOA Middleware:  Next Steps in SOA Series - June 2006

On portals and services

According to the ZDNet SOA blog service oriented architecture is driving a new portalmania.  I believe it. 

I find it nearly unfathomable that the portal industry has survived so long in the absence of SOA.  I suppose the promise of customization and fancy client interfaces have always held attraction, and thus have continued to sustain portal technologies to this point.  It seems a rather hollow promise to me without an underlying layer of services.  That said, I've recently refocused my technology radar toward portal technology in light of a burgeoning SOA effort.

In the beginning our SOA effort, with the support of a fairly well established EA, I was initially keen to separate my concerns and focus on developing the service infrastructure, initial service definitions, and communication on SOA to the business.   However, as time (and the SOA) goes on I find myself more and more becoming comfortable with the service architecture and implementation, and more concerned about the presentation layer.  After all, there's little point in a fancy suite of services that are not used, reused and accessible.