The Politics of Design

Forward: "Governance" is a word that gets thrown around a lot. For this article, "Governance" means the practices that are used to guide the architectural design of services. The goal is to increase reuse, and ensure the team is building toward a strategic, unified vision.


After our first attempt at service governance failed, we took a hard look at what was going wrong. We saw that we needed to move our involvement in the solution designs earlier in the cycle before commitments were made.

Historically, when we tried to get involved early, one of the concerns was that some projects could not bear the weight of full architecture oversight. Team members who were most concerned with budget and delivery would view forcing small projects into a complete architectural design and review process as overkill. However, we wanted to see and get involved in more important projects from the beginning. We needed a new process that allowed each project to understand what to expect from the onset. We developed the concept of "project categorizations"...

After creating our first service oriented framework, we realized that an effective governance structure would be key to protecting the value of the newly-built services. With dozens of developers creating a bunch of services, there would be plenty of opportunities for duplication of logic and ill-conceived, single-use services. Governance would ensure that the organization as a whole would follow a cohesive vision. If we expected standards and patterns to be followed, establishing a good governance process was a must.

We pulled together the Architecture Review Board consisting of the most experienced architects in the organization from all the primary disciplines. This group was tasked with reviewing designs from every project undertaken by the organization.

We met and critically reviewed the details of each project. We discussed the pros and cons of each design. We discussed, and argued, and provided open and honest feedback to the develop teams.

And... We failed. - Miserably. But today, with the benefit of hindsight, I can tell you where we went wrong.

Growing up on a farm can teach you a few lessons.

For example, when a fox first steals a chicken from your chicken coop, you have a right to be angry with the fox. Maybe when the fox steals a second chicken, you can still be angry with him. But, when he steals the third, fourth, and fifth chickens -- those are on you. You should be angry with yourself. The fox is being a fox. Although he could completely change his behavior overnight, it isn't very likely. It's more likely that the fox is going to keep doing what foxes do. The fox is predictable.

If you've been with an organization for long enough, you begin to get familiar with members of your team. Over several projects, you begin to understand how they behave. You know what they do well and you know where they have challenges. You learn that Henry's time estimates are too short, Theo's code is not unit tested, and Jack's always 10 minutes late to morning scrums. Your team members, like the fox, are predictable.

We’ve outlined 6 core values in this multi-part post:
1. Impact – the desire to create something great.
2. Courage - standing up for what you believe.
3. Tenacity – Never stop trying.
4. Unity - Progressing, as one mind, toward a common endpoint.
5. Sustainability – the capacity to endure.
6. Curiosity – a commitment to life long learning.

If someone held these core values and demonstrated them consistently throughout their career would they be a valuable member of your team? Can these values be learned? Are some of these values more important than others and are some more difficult to master?

Without fail, the guys that rise to be the cream in your development organization are the "learners".

There are "experts" in your organization. These specialists are incredibly good at what they do. They've been doing it for a long time. Their careers are built on the ability to do a task and do it very well. When you need a specific task done right AND right now, you go to the experts. Experts know how to get things done today. These folks are very valuable to your organization, but they aren't the learners that I'm talking about. Learners will know how to get things done in the future.

Architect’s must hold sustainability as a core value and seek a pragmatic balance for every solution.

This is more difficult than you might think. Many IT solutions don’t have set requirements to last a set number of years. How long should a software system last? 15 years? 5 years? 5 months? What about your enterprise databases or your ERP system? How long is that new Collections system expected to last or how about that quick 3rd party integration service?

Consider the below formula for solution sustainability.

Sustainability = (Requirement + Budget + Technology) / time to market.

Requirement – assuming there is no explicit requirement: has the business pushed for a longer lasting solution (5 points) or one that is temporary (1 point).

Budget – There is never surplus budget but does the business case support buying/building a solid application ( 5 points) or is the project sponsor line-iteming out error handling to save a few pennies(1 point)?

Technology – is the solution based upon mainstream, open technologies (5 points) or proprietary, legacy(1 point)?

Time to market – Is the project being rushed to meet some legal regulation or significant business opportunity/challenge (5 points) or can you create a reasonable delivery plan (1 point).

If this is the formula for sustainability then who determines the values for these variables and helps steer them toward the optimal level of sustainability possible for your systems?



Your project team is guaranteed to have someone pushing the time and cost dimensions…your architect needs to *balance* these with the sustainability dimension.

While the other core values may surface at various times, sustainability must be considered on every project. This does not mean building to outlast the business need…just building to last long enough.

Who is the steward of sustainability for your IT systems?