email article printer friendly

5 Practical Tips for Enterprise Architects
Apply practical strategies to make distributed development more effective for your organization and move your customers' businesses forward
by Dan Massey

May 8, 2006

In his national bestseller The World Is Flat, Thomas L. Friedman spends more than 100 pages describing "The Ten Forces That Flattened the World" (see Resources). Most of his examples center on how technology trends such as outsourcing and offshoring have changed and continue to change the world, and in most cases level the playing field for those not previously included.

As enterprise architects, we are well aware of the benefits—from cost savings to faster time to market—that our companies are hoping to gain from distributed software development. If your company is engaged in outsourcing, offshoring, or nearshoring, or if your team has been merged or acquired into a situation where software development is now distributed, welcome to the club.

There is no end in sight for distributed development. The current practices of dispersing different activities and phases in the development process will continue to grow. This growth is for reasons ranging from retaining talent, to pursuing a 24-hour workday and shorter development cycles, to everyone's favorite, saving money.

However, a recent Gartner research note entitled, "Globally Distributed Application Development Demands Improved Collaboration," calls out the challenges of distributed development (see Resources). Gartner analysts wrote, "Application delivery and maintenance by a globally distributed team, although potentially cost-effective, poses a risk that comes from geographical and cultural obstacles to collaboration, exposure of intellectual property to out-of-country geopolitical conditions, and from complexity of tracking project changes and progress."

I agree, but I also believe that as enterprise architects we have a unique opportunity—and responsibility—to mitigate some of these risks. Here are five ways we can do our part to make the distributed development initiatives within our own organizations (more) successful.

1. Communicate using a formal design language.
Communication is the number one challenge for anyone working as part of a distributed team. It's no exception with enterprise architects. Many of us were hired because we not only have effective engineering skills, but we also have the ability to communicate effectively—often a key point of differentiation between senior development staff and enterprise architect job descriptions. As we work with others outside of our locations, it's imperative that our communications stand on their own. PowerPoint slides and ad hoc Visio diagrams don't translate well across the country or around the world. For this reason, we should always describe architecture using formal design languages.

It doesn't matter whether you choose Unified Modeling Language (UML), Business Process Modeling Language (BPML), Alloy, or another design language, assuming you select one appropriate to the design task. The important point is that you use at least one. That way, you can ensure that the models you create will include the relationships and semantics you intended when viewed through the eyes of a reasonably literate reader.

My team has standardized on a specific subset of UML to help us specify, visualize, and document models of software systems, including their structure and design, in a way that is flexible enough to meets our requirements. We create UML 2 class, state machine, activity, component, and package diagrams, and we've also defined the subset of each type of diagram that our entire team must be able to read.

If we desire, we can now take advantage of new Model Driven Architecture (MDA) features, which include OMG's Query View Transformation (QVT) that is used in model-to-model transformations, and support for Object Constraint Language (OCL) 2. These features give us options for using the models as more than communication tools. We use other design tools as well, including XML schemas and business process models (using the BPM Notation), from which we can generate business process execution language for Web Services definitions (BPEL4WS).