Todd Biske: Outside the Box

James McGovern asks, “How come Enterprise Architects don’t embrace agilism?” He asked a number of us to share our experiences about how frequently we talk about agile methods. The first question I asked myself after reading his entry was, “What are we even talking about when we say agile methods for EA?” Agile methodologies have been associated with software development, and while the domain of enterprise architecture does include software development, it is not solely limited to that. So, I went to the agile manifesto and revisited its four values. They are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiations
• Responding to change over following a plan

So, what does this mean in the context of EA practices? Let’s look at them one at a time. Keep in mind that the original authors of this manifesto state these as preferences, not absolutes. All components have value, the authors simply believe that the items on the left have more value.

Individuals and interactions over processes and tools. This could easily be rephrased as “don’t become an ivory tower.” This is certainly something that all EA teams should keep in mind. If the only meetings you have are with other enterprise architects, there’s a problem. I’m a firm believer that information is power. Too often, we prevent the sharing of information because of fiefdoms that have been set up in the enterprise. Some are formal, some are not. It’s frequently a matter of trust. If you trust that the people you share information with will use it wisely, it gets shared. If you don’t, you don’t share it. Sometimes the lack of trust is justified, sometimes it is not. As far as the manifesto goes, however, the key word is interactions. Interestingly, in James’ post, he states, “Why not optimize the organization so as to reduce the amount of folks one needs to interact with in order to get the job done?” While you may think he’s dismissing interaction, which would be contrary to the manifesto values, I think the message is that you also need to understand your role in the organization. Interaction is important, to a point. As an individual, you need to make good decisions on when to interact and who to interact with. If you don’t, you lose trust and credibility. It’s like the Emotional Bank Account® from Seven Habits of Highly Effective People. As far as how this impacts EA, it really means that you need to get out and work with the people using your reference architectures and your strategic plans.

Working software over comprehensive documentation. Since most of what EA does is create documentation, the thing to look at here is whether the right documentation is being created. Again, the authors of the manifesto don’t say that documentation has no value. Documentation does have value, and EAs need to ensure that their own documents are targeted with purpose, as are the documents they receive. The EA needs to concerned about the items that will live on and be of importance to the enterprise.. The project architect needs to be concerned about the items that make the project successful. The two may not necessarily overlap. This ties back into my comments about roles and responsibilities. Without a clear understanding of roles and responsibilities, how will the project know when to interact with the EA and vice versa. Forcing a formal review process to mandate that some interaction occur is not a solution when the roles, responsibilities, and goals are not well understood. Formal reviews can be powerful, but only where they complement the interactions taking place, rather than replacing them.

Customer collaboration over contract negotiation. No arguments here. Unfortunately, we’re still in the state where the IT / business relationship is seen as customer / supplier, rather than working as partners. It ripples all the way back up to the information sharing, and ultimately, that can have a very negative effect on the solutions. If, as an EA, I’m not aware that the company’s strategy is to grow by acquisition, my focus may be in the wrong area, resulting in the integration costs being much higher than they would have been had I been in the loop.

Responding to change over following a plan. I had someone ask me once, “How do I make sure this service is an enterprise service?” I told that person, “You don’t. Instead, assume that your service will change and understand how you’re going to manage it.” The real problem is that we don’t plan for change to begin with. We think things can be etched in stone once and we’re done. Technology solutions in the enterprise, software development projects in particular, simply don’t work that way. The organization needs to figure out how to include change in their planning processes and accommodate it accordingly. This doesn’t mean throw out your project plans, but it does mean that a single annual review and funding cycle won’t work.

My final comments: Adopting agile methods is kind of like losing weight. Going to an extreme doesn’t work. You need to have moderation, finding the right amounts of each food and each type of exercise for you to be successful. The authors of the manifesto clearly state that they are articulating preferences, not absolutes. You may read James’ post and think that the we need less communication. I don’t believe that. I also don’t believe that more communication is the answer, either. I believe that we need more of the right kind of communication, and less of the wrong kind of communication. If you’re an individual in an enterprise, always ask the questions: Who should I be communicating with and should be communicating with me? Don’t wait for them to come to you and ask for something, and don’t wait for them to come and give you something you think you need. Get out of your chair and do it.

2 Responses to “Agile Methods for EA”