Your team has designed the perfect architecture for an SOA (Service Oriented Architecture) project. You are all excited and ready to get rolling. A few weeks later you find out that you will need to make several compromises in your design because of other teams’ skills and constraints. Your end of the integration is almost fully developed and ready for integration testing when you find out that the other end is still undergoing development, or worse, it is in still on early stages of design. Sound familiar? I have found these to be very common situations in SOA integration projects that span across two or more teams and/or applications. In this post I will explore five frequent SOA project pitfalls along with some recommendations that can help mitigate or avoid some of these roadblocks to make your project successful. You will find that these scenarios are not unique to SOA integration projects, but they also apply to most inter-group IT projects.

Too many “chefs” or lack thereof

An integration project often spans across multiple teams and applications. Each application may belong to a different group or to an external organization, each of them having their own tech lead or leads. Meetings become less productive and add project overhead. In spite of this, it is always better to involve all the relevant parties early on than later in the process.

More than often, “planning meetings” are not productive (i.e. decisions are not being made effectively) because there are “too many cooks in the kitchen”. In such situations, it may be necessary to attempt to reduce the number of attendees, or break the audience by role (e.g. have meetings with primarily business representatives vs. mostly IT representatives). If it gets too detailed, break it out in smaller meetings, however the challenge here is not to end up having too many meetings or leaving key people out. This is where good leadership comes into place, not necessarily from a technical lead, but more so from an overall project oversight. A project leader needs to have the authority and leadership to adjust direction when things are not moving productively.

Recommendation: Identify and involve key representatives from each party early on and throughout the process

Timelines and priorities out of sync

Different teams have different agendas and priorities. If you have not done so, count the total number of resources that are involved in the project, starting with developers, database administrators, testers ranging to business analysts and management. Unless you are in a very small organization, this count can easily reach several dozens. With these many resources, coordinating meetings, schedules, budgets and business priorities is a logistical nightmare. What can you do about it?

• Start with project management 101. Identify key dependencies factoring inter-group dependencies.
• Have a overall project manager in addition to application/group specific project managers.
• Try iterative development methodologies. The biggest mistake I have seen made is to attempt a waterfall model. If one group falls behind on the development phase, it will impact testing of other teams. Having smaller iterative phases helps minimizing the impact of one team on another.
• Define and agree on integration interfaces early on, but account for changes later on.
• Identify “bottleneck” groups or tasks, e.g. turnaround time for database changes taking 2 to 4 weeks.
• Early in the project, identify external dependencies where there is less control, e.g. dependencies on affiliate companies or third parties that may not have the same business priorities.

Recommendation: Integrated project plan and project manager; upper management oversight

Legacy applications break or do not comply with the prescribed architecture

Your SOA architecture relies heavily on web services and message queues. Guess what? One of the systems you need to integrate with is a legacy application written in some obscure language that nobody really knows or wants to even touch. This is one perfect example where you may need to compromise your architecture. It turns out that the only interface available to that untouchable legacy application is via text delimited files. A valid and common solution here is to add a layer in between which communicates via a service externally and internally generates the delimited field. Obviously if this untouchable legacy application is a business critical application, you should consider modernizing it, though that will probably fall into a completely different project.

The decision to make compromises to the reference architecture must also factor the cost versus the benefit. Perhaps the legacy environment already has the capability to communicate via web services or message queues, thus reducing the cost and impact of changing the legacy application.

Finally, the reference architecture should outline when compromises and exceptions are valid, although in practice exceptions may be project-specific. These must be carefully weighed and evaluated by the lead Enterprise Architect.

Recommendation: Make wise compromises (cost/benefit analysis) and modernize where possible

Where or who is responsible for implementing this?

You have spent several meetings with other groups debating where a data lookup should be performed. Group A argues that the lookup should be performed by Application B, because they are the consumers of that information. Group B strongly believes that it should be done within Application A because they already have other queries to that database. Both groups have a good case (purist vs. practical), but neither group gives in. Who is going to make the call? The Integration Czar.

The Integration czar is not a dictator, but rather a mediator with authority across multiple groups. Many companies already have this role in place. Perhaps a more politically correct term would be the Chief Enterprise Architect (CEA). This chief must obviously have a very good practical and updated knowledge of the latest technologies, as well as on the legacy technologies. Ideally it should be someone familiar with the existing key corporate applications, their architecture, design, documentation (or lack of).

This role does not have to be filled by a single person, it could be a small group of Enterprise Architects. The Chief Architects must also be leveraged to express technical recommendations and guidance to achieve consistency across IT projects. They should also be aware of team skill set, bandwidth and application technology stack to factor those on their recommendations. When needed, the CEA must dictate the best path to follow, such as in the situation outlined above. One piece of advice: when you have found a good Chief Architect in your organization, do whatever in your power to retain him or her.

Recommendation: Integration Czar or Chief Enterprise Architect (CEA)

Skill set, bandwidth or interest deficit

The project plan has a mainframe group developing web services, a technology that is completely new to that group. IT Management wants that group to learn that technology along with an object-oriented programming language. The problem here  is that it is not just one technology to learn, but a stack of technologies that may be completely new to that group. Even the most experienced and skilled developer will struggle and may get frustrated with the challenge.

Another common scenario is when key resources are not involved throughout the process or at the commitment needed. This can often result on making the incorrect assumptions which may translate in rework or missed tasks. A third deficit situation, and perhaps the most challenging, is having resources with lack of interest or motivation. Sometimes resources get allocated to the project because they happened to be available, but they may not necessarily have the right skill set or domain knowledge, and in most cases, project contributions are not tied to individual performance goals.

For years, universities have been very successful at having multi-disciplinary degrees creating unique synergies among complementary majors. Why not borrow that idea and actually apply it within IT teams? I know this sounds unrealistic because of independent company group budgets. But if you have a chance to experiment with this idea, I urge you to try it. For it to work, there must be mutual and even benefits. For instance, one team member may provide the technical skills in the form of mentoring, while the other provides the domain expertise. It also needs to be tied to individual performance/career goals on both sides of the fence. Having this joint collaboration can really help by putting one group in the other groups’ shoes and understand their challenges and needs better. Strive to find creative and new ways of collaboration and synergy to achieve your common goal: a successful project.

Recommendation: Multi-disciplinary teams

Be Sociable, Share!

•