The Making of a Governance Anti-Pattern?

Todd Biske has an entertaining post that may form the beginnings of a Governance Anti-Pattern creatively named Dilbert’s Guide to Governance. With amusing flair and a reference to a Dilbert cartoon, he asserts:

"If the only way someone knows whether the decisions they make are right or wrong is by attending a meeting and hoping someone with authority (if they even know who that is) agrees with them, that’s not good governance, albeit it is governance."

Related to my recent post on governance and goodwill, Todd captures an important aspect of the IT Governance practice: capability development. He points out that Governance is about "people, policies, and processes, in that order," and goes on to remind us that the processes we develop should be designed to motivate the organization for continuous improvement. Be sure to check it out.

Keeping Your Code Drawers in Order

Jeremy recently argued that you should "Put Code Where You Would Expect to Find It". He explains, "A team should strive to consistently put different types of code into separate, logical places in the structure."

I couldn't agree more, so I thought I'd echo that guidance and follow with a specific example. When organizing a project, try to establish clear conventions for what sort of code goes where and what it's named. The following represents an organization I've grown comfortable with, including a top-level folder structure and naming convention. This example is obviously applicable to the J2EE world, but a similar scenario could be described regardless of the specific technology stack.

• conf - Configuration Files
• web configuration files
• ejb descriptor files
• resource files
  
• db - Database Initialization Files
• ddl scripts
• sample data
• docs - Documentation Files
• architecture doc
• user guide
• readme
• release notes
• examples - Example Programs/Scripts
• xmlschema - XML Schema Files
  
• java - Java Source Files
  
• bo - Business Objects
• Class/File Suffix: "BO"
  
• client - Client Library
• Class/File Suffix: "client"
  
• dao - Persistence Classes: Data Access Objects
• Class/File Suffix: "DAO"
• ejb - EJB Implementation
• Class/File Suffix: EJB
• ejbi - EJB Interfaces
• Home Interface
• Class/File Suffix: "home"
• Object Interface
• Class/File Suffix: (none)
• test - automated tests
• Unit Tests
• Stress/Perf Tests
• User/System Tests
• util - utility/miscellaneous
• vo - Value Objects
• Class/File Suffix: "VO"
• webui - User Interface Source Files
• Models, Actions, Views, Forms, etc
  
• web - Web Content
• html, jsp, css, images, etc
  

This sort of consistency encourages better design, reduces defects, simplifies knowledge transfer, improves impact analysis, and reduces support and maintenance costs. It can even encourage better estimates. And the value is even greater on large-scale systems consisting of many similarly consistent sub-systems. On those types of systems, the benefits of good discipline accumulate exponentially.

Test Driven Knowledge Management

James Carr had a nice piece recently on Test Driven Development (TDD) Anti-Patterns in which he begins to build a catalog of anti-patterns to be on the lookout for. The underlying principles embodied in these anti-patterns apply to unit testing of many sorts, and two of the entries in James' catalog speak to an important purpose of automated unit testing that is sometimes downplayed.

The Enumerator
A unit test with each test case method name is only an enumeration, i.e. test1, test2, test3. As a result, the intention of the test case is unclear, and the only way to be sure is to read the test case code and pray for clarity.

The One
A combination of several patterns, particularly TheFreeRide and TheGiant, a unit test that contains only one test method which tests the entire set of functionality an object has. A common indicator is that the test method is often the same as the unit test name, and contains multiple lines of setup and assertions.

These two anti-patterns hint at the value of automated unit tests as documentation. Well-structured unit tests establish an impenetrable border around a module and serve many purposes, including documentation of the anticipated behavior in a very tangible manner. During development, this serves as a specification of sorts. Later, during product maintenance and support, these unit tests continue to serve an important role in the Knowledge Management capability, providing ultimately meaningful and contextually relevant documentation of the expected function of the module. What's more, this documentation is virtually guaranteed to be current and accurate.

Of course, the role of unit tests as documentation is secondary to the more direct quality implications, but it's always good when we can get more bang for our buck.

Ridiculous Simplicity (#2)

As we've looked at before, simplicity is a funny word. Sometimes hard to understand. Always hard to accomplish.

As Software Architects, one of our greatest responsibilities is to vacuum up the chaos and distill it into a rational and valuable (even pleasant) reality. One of the keys to success on this dimension is simplicity, which I tend to think of in the following ways:

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupery)

"Simplicity--the art of maximizing the amount of work not done--is essential." (Agile Manifesto)

"Treat every problem as if it can be solved with ridiculous simplicity. The time you save on the 98% of problems for which this is true will give you ridiculous resources to apply to the other 2%." (Dr. Paul MacCready)

"80% of the results come from 20% of the effort." (Pareto Principle or 80/20 rule)

Finally, as I'm defining it, the goal of simplicity is nicely summed up in the following quote from Paul Preiss, President of IASA, in a recent webcast, "A Guide to the Architecture Profession":

"Our responsibility is to build as little software as possible to add shareholder value."

Let's get out there and build less software! Oh, and lets simply do it with less effort!

Governance Without Goodwill is Dead

OK. I may be pushing it. It may not be dead, but architectural Governance outside a framework of goodwill and mutual respect is a rugged road fraught with challenge, frustration, and diminished effectiveness.

When we form architecture teams and governance capabilities, it's wise to keep in mind that the average development community is a fairly cynical bunch. Truth be told, I count myself as a charter member of that fellowship. It's not that we're jaded or negative; in fact, I think it's a healthy sort of cynicism. Developers want to solve problems. They're wired that way. It's in their heart. Anything that appears to be a roadblock or speed bump on the way to solving a problem and delivering results triggers an instinctive, almost immunological response. That's a good thing, right? Developers who anticipate and overcome interference with goal accomplishment are the most sought after and highly prized. The most valuable developers are those who demonstrate the greatest skills at recognizing potential problems and circumnavigating.

Given this postulate, we can recognize the opportunity to take specific actions to ward against the natural immunological antibodies that, if left unfettered, would work to reject a "foreign" obstacle such as Governance. Fortunately, in this case, the solution seems to be one that passes the obviousness test. By recognizing the development community as important stakeholders of programs such as Governance and pursuing a model that appropriately balances potentially competing stakeholder needs (something good architects always do), we are able to engender goodwill and gain active support from the community at large.

Fundamentally, the solution lies in helping the development community understand the problems being addressed with programs such as Governance. By clearly articulating the business drivers - and like all good business requirements, these should be expressed in the problem space - we engage the teams' problem-solving energy and channel it in a constructive direction. Simply put, we point it at the designated target. When people understand where we're trying to go, they're inclined to be more supportive.

But it's not enough to simply "understand." It's also important to "believe." John Kotter talks about this as the need to "Increase the Sense of Urgency" in The Heart of Change: Real-Life Stories of How People Change Their Organizations. When expressing the business drivers that motivate Governance or other change initiatives, we're well served by establishing an emotional connection to the need for change. Kotter puts it like this, "Go after the emotions with concrete and almost smellable evidence, not just abstractions so favored by the rational mind. Use evidence you can see, not just words and numbers."

With this foundational understanding of the problem and why it must be solved, we can invite participation in the solution. By engaging the "right people," a sense of obligation and commitment is established on the inside of the community, and the people start saying, "We have a problem, and we must do something about it." I like to call this an "inside out" approach in contrast with the myriad less effective (but unfortunately more common) "outside in" techniques. When we come at it "inside out," we create goodwill (earnest hope that something will succeed) within the community that serves as a source of energy to motivate people toward the desired goal.

The “right people” are the key to unlocking goodwill, and it’s important to recognize they’re not necessarily the current senior management. Creating a Governance capability (or implementing any change of this type) is not a management activity. It's a creative activity that requires people with leadership skills who possess the expertise and credibility that is meaningful within the given community.

When you set out to create a Governance capability, be sure to include the development community among your list of influential stakeholders. Go out of your way to establish goodwill by working “inside out” with the “right people”. The rewards will be great.

Secrets of Collaboration

It's increasingly important for Architect's to exhibit effective collaboration skills. For example, innovative ideas, trust, and teamwork thrive in a collaborative environment (and we know that trust and communication are precursors to results). Also, many of us find ourselves working with teams that are geographically and culturally disparate, a situation that demands even greater collaboration - more creatively.

In this light, Alistair Cockburn recently gave a sneak preview of an article he's working on about improved collaboration. He highlights the following practical techniques:

• Lift others
• Be courteous
• Add energy to the room
• Listen intently
• Inquire (don't argue)
• Recognize others
• Challenge but adopt other suggestions
• Increase safety
• Be yourself
• Say something honest and true, but on the edge
• Support someone else who is at the edge of their comfort level
• Challenge but adopt other suggestions
• Get results
• Make sure there is a known goal
• Get one result (then get more)
• Focus, get back from diversions

These suggestions are provided in the context of a specific engagement or meeting, but many can be applied in general. Reading through the list, I'm reminded of principles such as "Seek first to Understand" from The 7 Habits of Highly Effective People and "Vigourous Debate" from Good to Great: Why Some Companies Make the Leap... and Others Don't. These are not only essential characteristics of a healthy and productive culture, they're essential skills of the Software Architect.

Which Came First, the Trust or the Results?

Trust is largely earned and maintained through relationships in the presence of results.

In The Five Dysfunctions of a Team: A Leadership Fable, Patrick Lencioni makes a case that trust is foundational to the behavior of a team - trust sufficient to allow honesty and vulnerability. This forms the basis for performance in today’s complex corporate contexts and allows a team (or a company) to overcome several potential roadblocks:

• Fear of Conflict
• Lack of Commitment
• Avoidance of Accountability
• Inattention to Results

It's typical in today's climate to find the relationship between IT and the Business at a tenuous place. Fortunately, open communication, commitment, accountability, and results lead to greater levels of trust. As trust (between team members, partners, etc) increases, we strengthen communication, and a cycle of positive reinforcement between trust and results has begun. More trust -> (communication, commitment, accountability) -> more results -> more trust. The flywheel is beginning to spin, and we’re building a high-performance culture that is able to efficiently deliver value to the business.

The Architect is an important part of this system.

Communication

Able to understand the needs and interests of both the Business and the IT communities, the Architect is uniquely positioned to communicate in meaningful ways, helping to ensure mutual understanding. This "bilingual" capability leads to less ambiguity in language and helps to establish confidence. Confidence and mutual understanding open the door for open and honest dialog with "vigorous debate" when necessary. This level of honesty and vulnerability establishes a wide-open channel for high-bandwidth communication.

Commitment

I heard a quote once that went something like this, "We would rather have one man or woman working with us than three merely working for us." I think this is what the business wants from IT - a partnership. And like nearly all partnerships, this one comes with the need for each partner to feel secure and confident in one another, able to emerge together from the risky situations we find ourselves in. As usual, a partnership won't thrive when challenged with "commitment issues".

Accountability

The Architect has ultimate accountability for the technical results of a project. When things go south, people should turn to the Architect to recover... and explain. See The Architect Is Accountable!

Results

"The architect and client meet when it is all over and reminisce about the trials and triumphs. They hold a big party at a Mexican restaurant, complete with Mariachi Band, for all the builders, employees, and customers involved with the project. Those nay-sayers who whined incessantly and said it couldn't be done now stand mute, sipping their margaritas." (http://www.wwisa.org/wwisamain/role.htm)

Perhaps we should say the Architect is on the hook for keeping the "Flywheel of Trust" spinning. And the margaritas flowing!

Others have written on this topic recently. Check out Todd Biske at SOA requires trust and Alastair Bathgate at IT and the business (yet again).

Most Important Competencies of the Software Architect

What competencies of a software architect are most important to you?

I asked this question recently at LinkedIn and was encouraged by the responses that consistently exposed the importance of the architect's role in balancing the business and technical domains and demonstrating "soft skills". We know from prior entries that these competencies are often overlooked in an architect but are critical to success.

For quick reference, here's a summary of the responses. Be sure to check out the thread for all the details.

Communication

• Understand stakeholder needs
• Ensure the stakeholder's understand the capabilities and limitations of the architecture
• Gain consensus on approach through diplomacy, compromise, and mediation

Business Orientation

• Understanding the business/domain
• Be aware of financial implications, including costs vs. benefits
• Discover opportunities to make trade-offs that maximize value to the customer

Technical Orientation

• Quickly grasp the ins-and-outs of the technical and functional domains
• Work with the development teams to make sure the target is met
• Don't gloss over the details - but don't get buried
• Assume accountability for product delivery
• Manage scope
• Provide technical expertise

Leadership

• Think in the abstract - cut through the clutter and quickly arrive at viable solutions.
• Know when to stay in the abstract and when to go deep
• Engage the teams and build passion for the vision
• Demonstrate commitment to continuous improvement - for self and team
  
• Be open minded, innovative, and creative
• Delegate

Judgment

• Harvest patterns and relationship out of detail and build meaningful models and abstraction
• Make good decisions
• Focus on the right things

There was one additional response that I'd like to call out specifically. We've previously discussed the importance of the Architect as a "doer", and we've asserted that architects are frequently at an advantage if they're able to bang out code (at least in appropriate circumstances). Others have also written about this. One response to my question about important competencies offered a practical perspective on this topic:

...designing without coding looks to me as not speaking the same language with the developers - again a communication barrier.

A good point.

One last thing. Be sure to compare this list to the definition of a Software Architect. You may also like to have a look at the competencies that are required by the Microsoft Certified Architect (MCA) program.