Application architecture essentials, Part 5: Build process management compliance into your design

Simple techniques to ensure accurate and consistent architecture design use

Process management is a key element in any application architecture design. Learn how to build process management compliance into your architecture design to ensure that it's used consistently throughout the organization.


S. E. Slack (, Author and business transformation communications consultant, Freelance writer

author photoS. E. Slack is a Studio B writer and author with more than 16 years of experience in business writing. She has also been an executive and business transformation communications consultant to IBM, Lenovo International, and State Farm Insurance Company. She is currently writing CNET Do-It-Yourself Digital Home Office Projects: 24 Cool Things You Didn't Know You Could Do (McGraw-Hill) and is the author of five other books.

01 May 2007

Also available in Chinese

Part 4 of this series discusses planning for growth in your application architecture by showing you how to focus on customer-centric business strategies using scalable and adaptive thinking. Now, in Part 5, you learn how to build process management compliance into your architecture design to ensure that it's used consistently throughout the organization. This is a natural evolution of the scalable and adaptive thinking concepts addressed in the previous article, so be sure to read that article along with this one so that you fully grasp those two conceptual ideas and can apply them to the process management techniques outlined here.

Process management refers to having the right procedures in place to ensure that teams execute critical activities required to improve productivity and guarantee a level of control to best manage the organization. Process management is critical in application architecture design. Without it, your design is at the mercy of departmental politics, and you'll find yourself going back to the drawing board time and again in an effort to please the various powers that be. Worse, your design may not be implemented and used properly if process management techniques are only talked about but not followed.

With strong process management compliance, however, comes a level of control that can literally stop arguments before they occur. Departments won't be able to break away from the pack to follow their own designs, for example. Architecture designs are respected for the level of productivity and efficiency they bring to the organization. Whether or not you're a key player in the development of an organizational process management system (most application architects aren't), you must fully understand the process management techniques that your organization uses, and you must consider how to use those techniques to your advantage.

Skills and competencies

Several skills and competencies are required to effectively build process management compliance into your architecture design. As you read through each one, try to focus on the processes and people that will be involved in bringing your vision to reality.

Coaching and arbitration

As you help implement your design, don't be surprised to find yourself using two essential personnel-type skills as the design works its way through the organization: coaching and arbitration. In some ways, process management is equal parts negotiation and insistence that processes be followed. Human nature is such that people don't like to be told to follow the rules. Yet, if a process is going to work effectively, the rules must indeed be followed. The trick, then, is to coach people into using the processes required for your design even as you sort out disagreements and attempt to make your design more attractive for users.

Before you say, "That's not my job!" consider for a moment what your job is: to create a design that your organization will use consistently and effectively. If it isn't used in that manner, your design is not well planned and executed, right? Application architecture doesn't stop after the design is created and approved for implementation. In reality, it never ends as long as users are involved. And if they need some prodding to use the design, then the architect needs to jump in and prod wherever necessary.

The role of an architectural coach is to create the right conditions for learning to occur as well as to find ways to motivate users to accept the new design. To create the right conditions, you must work with education teams to ensure that the right training is being created for users. In addition, you should contact communications teams to offer your expertise on the design for the various communications that will go out about the new design and its implementation. Don't wait for either team to contact you: They might not even know you exist! Chances are good that they are working in a bit of a vacuum as they try to understand how the design ultimately affects users. Offer your services as a subject matter expert as early as possible; it will give you the opportunity to coach others about your design in a multitude of ways.

Ah, arbitration -- also known as mediation or the "settling" of issues. You can play a big role during process management discussions by listening for areas in which you can improve your design to make processes easier for users. This particular skill is one that involves a lot of listening -- and it's one that can directly affect the usability of your design. If you're hearing others complain that a particular process built into your design is difficult to manage or follow, consider how you can manipulate the design to make all sides happy. Perhaps you can change your design to make a particular process easier -- or even eliminate a process that makes everyone crazy. Observe, analyze, and then provide your feedback on how your design can improve processes to make lives easier. You'll find that your willingness to adjust your design to help with process management issues will go a long way toward obtaining user acceptance in the long run.


Another skill needed to ensure process compliance for your design is management. I'm not talking about managing your time or other people; I'm talking about managing others' expectations. Here's what I mean: Any new application architecture design is likely to involve some sort of change in the applications people use within your organization. Maybe applications are being upgraded; maybe they're being changed completely. In the end, users expect the changes to result in something better -- simpler interfaces, less-complicated processes, and so on.

Whether you're managing your first design project or your fiftieth, you have the authority to make an incredible impact upon your organization. That authority is of little use, however, if those affected by your design don't understand what it's supposed to do. So take the time to set expectations up front and to keep communicating those expectations to everyone involved in the approval and implementation of the design.


Getting the message across clearly and unambiguously is a completely different story. How you communicate with others in the business environment can mean the difference in obtaining the acceptance you need to get process changes implemented. In my article, "Obtain approval for your process change recommendations," you learn specific techniques for communicating effectively to executive levels. You can use those same techniques for users and mid-level managers, too, as you work toward gaining compliance with the processes required for your design.

People like to feel as if they have an important role to play when a new application is rolled out: It's exciting to learn something new, but it's a little overwhelming at the same time. Polish your communication skills to help the education and communication teams build on that excitement and improve the adoption of your design throughout the organization.

Tools and techniques

Now, as we cover the tools and techniques that you can use to build process management compliance, consider the ways that you can make your design as simple as possible. The simpler a design is to use, the more broadly it will be used.


One of the easiest ways to build process management compliance into your design is to create a design that uses automation wherever possible. For example, do sales representatives need to remember which screens to move to, or will your design move them automatically through screens based on the answers received to specific questions? If your design relies on humans to remember processes, compliance will be extremely difficult. People get distracted, they have bad days, and they sometimes just decide to skip a certain piece of the process because it's time-consuming or difficult.

Automation, however, can literally force process compliance. For example, if the sales department needs follow-up information based on a specific response received from a customer, ensure that your design instantly takes the sales representative to the screen or application in which that information can be entered. This approach helps your organization innovate and revitalize performance more quickly, which leads to the ability to meet evolving business needs.


Your complete application architecture design should be a unification of all perspectives from your organization. When you think about it in those terms, it makes sense that organizational processes should be unified in your design as well, right? Sometimes, that means combining or eliminating processes; sometimes, it means creating new processes that are easier to use.

Let's say that your organization has a variety of business processes that use individual authentication applications. The applications are hosted at different locations on different hardware and use different operating systems and servers. To effectively support process management goals, your design should unify these multiple authentication applications into a single application that's easily accessible to every business process requiring authentication. Look at the process requiring the most complicated aspects of the authentication procedures, and start from there to build your unified authentication process. Build in some flexibility for the business units that don't require excessive authentication, and you now have a design that unifies processes by using all perspectives.

Process mapping, roles, and responsibilities

If you're confused about where to find information about various processes within your organization, you're not alone. Many organizations view process management as a nuisance, and few have taken the time to document processes across the organization. If your organization does have documented processes, get hold of the documents and be sure that you understand which processes your design will affect as well as who handles specific roles and responsibilities.

You're at a disadvantage if your organization hasn't documented its processes, but you can overcome that disadvantage by going directly to the business units and working with them to document their processes and discover the people behind the roles and responsibilities. (See Resources for a link to information about doing so.) It will take a lot more work on your part during the beginning phases of your design, but ultimately, the direct input you gain can go a long way toward building acceptance for your design.

That's because regardless of which method you must use to map and understand your organization's processes, you'll also discover the key business control points and metrics that each business unit uses to determine success. As you consider different approaches for your design, keep those control points and metrics in mind -- when business units see them (or understand that they're built-in behind the scenes), they'll be less likely to circumvent your design for their own, home-grown solutions.


Now that you've considered the people involved and the methods for making your design as attractive as possible, you must meet a few milestones. As you review the following suggestions, think in broad terms: How will your design fit into the overall scheme of things within your organization?

Take an inventory of all applications

Before you can build process compliance into your design, you must know which applications are used in which areas of the business. With any luck, your organization already has an inventory of applications. In reality, however, most architects just aren't that lucky. If that's the case, you must contact every business unit that your design affects and get a comprehensive list of the applications used, then compare those applications from business unit to business unit.

An application inventory helps you see where there are gaps and overlaps within the organization. For example, perhaps the sales and lead-generation teams use the same customer relationship management (CRM) application. But the marketing team uses a completely different CRM application that doesn't integrate with the first CRM application at all (although it does integrate beautifully with a third CRM application that supply chain uses). You won't realize these far-reaching implications, however, unless you have taken an inventory of all applications in the organization.

Document everything

As you create your design, document the processes that will change as well as how those processes will change. Regardless of whether your organization has an effective process-documentation procedure, your own documentation will help you as you explain the new design. You'll be able to point people to the documentation so that they can see exactly what your design means to them, and you'll never be caught off guard when someone challenges your design decisions.

Using an enterprise process framework such as the open source Eclipse Process Framework (see Resources) can help you with this milestone. Process frameworks help you leverage existing best practices across the organization as well as provide some level of consistency.


When you've completed all the research and documentation for your organization's processes and incorporated that information into your design, it's time to make your recommendations. Executives will want to know about budget constraints and competitive issues along with details about your actual design. Be sure to address these questions when presenting a recommendation to upper management so that you don't get sent back to the drawing board to figure them out. It's a good idea to present your recommendations in a written format to accompany any verbal presentations -- people learn in different ways, and some will need a visual representation to clearly understand your recommendations.


All the pieces addressed here are methods for ensuring that process management compliance is built into your architecture design to ensure consistent use throughout the organization. While it might be tempting just to reinvent the processes as you create your design, that's a dangerous approach to take. Without acceptance from the business units and solid reasoning behind why a process should be changed, your design is at risk for misuse. People will circumvent processes they don't understand or support; instead, make sure that your design is full of reasons to comply with processes.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Application architecture essentials, Part 5: Build process management compliance into your design