The Politics of Design

Architecture or Arrogance?

mike.marshall@politicsofdesign.com (Mike Marshall) — Tue, 09 Mar 2010 14:00:00 +0000

Are you confident in your architecture? Does that confidence appear as arrogance to your co-workers? Is it arrogance? How do you know?

There is a certain degree of confidence that must come with your job. In architecture, you're expected to provide some guidance. Architects are guides. If you were following a guide through the rain-forests of the Amazon, and he appeared to be mixed-up, second-guessing himself or otherwise unsure, would you still follow him? Or, would you ask for a refund from the eco-tourism people?

Commitment is a part of it. There is a possession shift when you are committed. You start speaking in terms of "my project" instead of "the project" or "your project". As you internalize an effort, and make it part of yourself, your posture changes and language you use becomes more directing and less about weighing options. When your guide believes that his well-being is connected to which fork you choose in the trail, he'll be more adamant about the decision.

There are times when you are unsure. During the early phases of a project, you have some basic signposts. You have some ideas and concepts strung together. You think they will play out, but there are doubts. Still, if you want to predict the future, you want to provide strong, clear direction. Even if your guide doesn't know the end destination, he still knows that it is better to follow animal trails and stick close to rivers. So, experience plays a role.

But, is it arrogance?

It is not arrogance if you are still listening. As conflict arises, you cannot take a "my way or the highway" approach. Alvo talked a lot about this in the recent "Playing Devil's Advocate" post. There is no perfect plan, and being open to refinements and changes in approach is an absolute requirement. The natural evolution of your direction comes from the whole group and ultimately adds to your base of experience in the future. If this never happened, our group of explorers would never venture into undiscovered country.

It is not arrogance if you are objectively supporting your positions. Taking the time to develop and communicate the value propositions that come along with your direction is important. Without this, your team will be quick to dismiss the guidance as hubris and ego. Discuss your positions openly and include both the positives and the negatives so that everyone understands your view and the reasons you want to pursue a particular path. No one should be expected to blindly follow a guide, no matter how many times he's been in-country.

So, in the end, a carefully considered and communicated direction, based in experience and commitment, and open to improvements is architecture -- not arrogance.

Agree? Disagree? Let us know in the comments...

photo: iansand

Fun size your design

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Tue, 02 Mar 2010 05:40:00 +0000

Software systems are complex beasts. Years of layering on intertwined business capabilities, extending with new technologies, and the special touch by "that guy" (who was trying something 'cool' he read in a book) can make the best architectures difficult to understand and extend after years of productive use.

When the day comes to make some substantial changes, or replace, this workhorse, you'll need time, money your best folks and "fun sized units of work". Entire books are written on the practice of software architecture and design but I wanted to touch on the importance of decomposition in design.

I've watched skilled technicians collaborate and decompose complex problems and chunk them into "fun sized", digestible units of work so that everyone in the room has a good understanding of each piece. Some times the pieces will even end up with names that the group will begin to address them as.

Digestible composition is also one of the axioms of OO Design. The human brain can only hold a finite amount of information in working memory so large procedural programs were very hard to understand and digest. Once you understood what an object/component/service does, you can leverage it based upon its interface and move on to higher value activities rather than crawling code to recall what happens on line 10,000.

Decomposition Revisited:
I learned this skill at some point in my career and have applied it to the point where I haven't given it any thought until recently I heard an interview with Johna Lehrer regarding his book called "How We Decide". In short, the book is study of decision-making from a neuroscientific perspective. While neuroscience may have your mouse wandering to the next Woot.com deal, I reconnected with this old approach on decomposition of larger problems into a set of smaller, digestible ones.

Emotional vs Logical Decision Making:
Lehrer's book outlines a study (among others) where subjects were asked to memorize a series of numbers. One group received small numbers and one group received large numbers. The subjects were then tempted with some food choices and the study showed that the subjects who had smaller numbers made better, rational decisions. Subjects who received larger numbers, made poorer, emotional decisions. The conclusion is that when you brain is overloaded with detail, you tend to make poorer, emotional decisions.

The number of items in the overloaded subject group is important here. Princeton Professor George Miller established what is often referred to as Miller's Law which theorized that the human memory span was limited to approximately 7 related items. He calls these items "chunks" which represent "largest meaningful unit in the presented material that the person recognizes". So, a chunk could be a number or...software component.

Decomposition is more than just a good idea:
All of this made me realize that decomposition is not just a good idea, it impacts our decision making and how well our systems are designed. It probably also explains the poor decisions made when we're overloaded with information which, according to Miller, has a threshold of around 7 related items.

So, if you find yourself struggling with the right approach or having a hard time moving toward the right solution as a group, make sure you think: 6-pack and fun sized!

All of this probably also explains why I always gain weight when working on long-hour projects.

More on Miller's Paper here.

photo: Fun

Sell the "Center 60"

mike.marshall@politicsofdesign.com (Mike Marshall) — Tue, 23 Feb 2010 14:00:00 +0000

Almost everything you do as an architect is "selling". Through your influence, you are selling executive management on architectural strategies and developers on architectural approaches. You are convincing project managers that your approach is the right one, and business managers that the solution will meet his requirements. All the fancy design artifacts serve the design need, but for many stakeholders, they are simply marketing collateral.

Sales is a numbers game. A percentage of the people are going to buy what you are peddling, so reaching out to more folks is the key to increasing your sales. Every sales presentation has a limited amount of time, and it's tough to touch all of the folks, so you need a strategy. What's your approach? When you leave an architectural presentation, how do you make sure that the largest number of people are bought in?

It doesn't matter what or how you sell...

It really doesn't matter what you are trying to propose. It might be an approach for a new system. It might be a process change. It might be the roll out of a new development framework. Sooner or later, you have to sell it to your whole organization. This might be done in small groups at a time. It may be one on one conversations with each stakeholder. On the rare occasion, it might be a the grand presentation complete with slides and handouts. In each case, you need to assess your audience and understand its make up.

There are 3 subsets of people in your audience, and interestingly enough, selling to two of them is a complete waste of your time and energy.

It matters "Who" you sell...

About 20% of your audience is already bought in. Selling to the "Believers" feels good. When you're making eye contact with them, they're nodding. They're sitting in the front row. They're receptive and it's actually fun to sell to them. They get it, and they're willing to add the enthusiastic "Hallelujah! Amen, brother!" responses at all the appropriate intervals. If you spend time selling to them, you are not moving the needle at all. They're sold, and any further selling to them is only just reinforcing your ego, and wasting everybody's time.

Another 20% of your audience are the "Non-believers". They have their arms crossed. They look like they want to be somewhere else, and on occasion they may even roll their eyes at your presentation. No matter if you're the most dynamic salesman with the most compelling story ever told, they are simply not going to buy it. It is easy to be trapped into thinking that if you can sell them, you can sell everyone. Concentrating on cracking these hard shells is a challenge and if you believe in your proposal, it's difficult to ignore it. You want them to believe so bad! They don't. They never will, and further selling to them is, again, just wasting everybody's time.

Sell the "Center 60".

The remaining 60%, the center 60%, is where your focus should be. They're not nodding, and they're not shaking their heads. They are listening. They are trying to understand the proposal better. They are looking for the advantages and disadvantages and weighing the pros and cons. They are the people you should be looking at and making sure that they are understanding each point. Your time is limited, and spending it concentrating on these people is the best use of it. Your ability to sell this "Center 60" can ultimately be the difference between failure and success.

Have you had success (or failure) selling your ideas? How? Why?

photo: gunnsi

Success - Intelligence or Grit?

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Tue, 16 Feb 2010 15:15:00 +0000

Intelligence or determination…which would you choose to have more of? More intelligence may just make you more of a “brilliant slacker”. More determination could be the missing ingredient to make things happen in your life and career even when the cards don’t fall in your favor.

You've run across the guy in the corner office, or the gal with the lofty title and wondered "what did they do to get there?" Intelligence? Work longer hours? Married the boss’s daughter or maybe better at puckering up than you are?

Maybe…it’s good ole’ fashion grit. Sticktoitiveness or downright determination. Granted, there are people who happened to be in the right place at the right time or leveraged relationships to get where they are but I'd bet if you look around you there are many people who are where they are because of dogged determination. Determination that’s been there all of their career.

Angela Lee Duckworth, PhD, who studied at Harvard, Oxford and is now a Professor at the University of Pennsylvania conducted a study on grit as an ingredient in success and a differentiator in achievement.

Read about the study here:
www.apa.org/monitor/nov07/grit.aspx

You can test your grit here. Look for "Grit Survey":
www.authentichappiness.org

Got Grit? Post it! I scored 4 out of 5 and was in the 90% percentile in all areas. The study is easy to cheat but answer honestly if you want to understand your true grit score.

photo: Grit

The Cost of Losing a Big Hitter

mike.marshall@politicsofdesign.com (Mike Marshall) — Tue, 09 Feb 2010 20:17:00 +0000

The past 18 months have been pretty tight for your organization. Revenues were down, budgets were slashed, and every tiny expenditure was re-assessed . Some people were let go, and the ones that remained understood that they had to dig in and get things done. Your workloads were increased, and you often had to take on duties that were not in our core responsibilities. But that's OK. When the going gets tough, the tough get going.

But the dawn seems to be breaking a little. Organizations are starting to expand in targeted areas. Some strategic projects are starting to get approved instead of delayed as they were 12 months ago. Departments are starting to look around for a few good people to augment their current teams. Other organizations are looking to add strong, well-experienced team players. They're only adding just a few, and they want the cream of the crop. So they're seeking experts.

They're Seeking Your Experts.

If your best and brightest have been heads-down working all angles of projects to fill gaps left by recent cutbacks, they've been doing work that is not their core passion. Business analysis, requirements gathering, design, development, testing, sorting out production problems, and project management is all work that needed to get done, and given the economic climate it had to get done, but your big hitter isn't thrilled to be covering all of those bases.

Retention needs to be a topic of conversation in your organization today. Even if some of the leadership suggests that the budgets are still too tight to support retention activities, it needs to be done. It may not seem like a burning issue yet, but a small investment today will offset huge costs in the near future. This is when you need to apply the proverbial "ounce of prevention".

The cost of retaining an expert must be weighed against the costs that you will incur should he or she walk. Consider the following areas:

Chaos and Momentum Loss - Just the amount of wasted time that is incurred in the week following the announcement is expensive. This is the cost of discussing the change, and the potential organizational impacts. The water cooler is buzzing. People start to chatter about the news rather than focusing on the work at hand.

Recruiting Time - An expert is someone with a solid skills and significant experience. You can expect that a replacement is not hanging around near the bus stop. It will take a significant investment of time and energy to find, recruit, and negotiate the hire of this person.

Spin-Up time for the replacement - On day one, the new recruit won't be particularly effective. In fact, the new recruit may not be particularly effective on day 180. It can take up to 12 months for a new person to understand the technology and business landscape of your organization. If he's only half-effective, the cost of half of his salary is sunk into this learning curve.

Costs to acclimate to the cultural landscape - Your culture is another area where the new guy will need to spin up. Understanding which executives base decisions on hard data versus who is more likely to make gut decisions is important. Knowing how to navigate through barriers in your project life cycle smoothly is a valuable skill to gain. Even worse, the replacement may never find a mesh with your culture and ultimately leave your organization, too. This resets the clock and the budget to square one.

Small shifts in Direction and Guidance - No two experts have the same approach and views about any subject matter. If your experts spend a good deal of time advising, instructing, and mentoring your staff, your staff will need to adjust to shifts in direction. This is a cost multiplier across your staff with each member burning hours adjusting to new ideas and guidance.

Loss of a Single Project - If amid all of these issues, your newly hired expert makes a mistake (and who could blame them if they did?), that mistake may result in the loss of a project, or in a result that will need to be refactored in the future. What would the cost of that be? How deep could that money pit grow to be in the future?

All totaled, the costs are very high. If your leadership is suggesting that budgets are still too tight to consider doing something to improve retention this year, I'd suggest you ask how much larger those budgets will be in the future when they'll need to address the results of this short-sightedness.

Lose any good experts lately - let us know in the comments.

photo: Billie Hara

Playing Devil's Advocate

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Tue, 02 Feb 2010 04:48:00 +0000

Conflict is a natural part of our lives and is a useful tool in finding the best possible solution in the shortest amount of time. Knowing when and where to wield this tool takes some practice as well as awareness of the impact on those around you.

Sometimes, conflict is treated like a game of skill or strategy. Much like a chess match, contestants end up in a mental game of wits trying to outmaneuver their competition. Others take on a gladiator-esque approach, sparring to see who has the stronger personality or will.

Conflict is a very useful tool but might be abused as much as it is used properly. Here are some coaching points to keep in mind to quickly get to an agreed to solution.

1. Make sure there’s a problem to solve. How many times have you heard two people debating a point in “violent agreement”? I like the definition of a problem outlined in the book “Are Your Lights On?” where the author defines a problem being the difference between desired and perceived state. The gap between where you want something to be and where you perceive it to be is the problem. No gap, no problem. Small gap, small problem. I’m not saying that level of conflict needs to match the level of the gap, but you should consider the size of the gap from your perspective as well as the others you are trying to influence.

2. Don’t get too emotionally involved in the discussion. It is easy to get wrapped up in something you’re passionate about, especially when you are being challenged on your position to something you feel strongly about. Don’t let the conflict turn from pragmatic to posturing. Keep in mind why you engaged in conflict in the first place which was to solve a problem, not to win an argument. If you maintain that position, the other individual will generally come around.

3. Make sure you are forward focused. Conflict can be used to determine the solution to a current / future problem but it won’t solve past problems. If you are looking for a problem with something that occurred in the past…you’ll find it. Nothing’s perfect so if you find yourself debating something that happened in the past you’re most likely not solving a problem so conflict is not going to help in this situation.

4. Watch out for conflict voids. If you rarely engage in conflict with the people you work with you are either part of some alien race where everyone sees with one mind OR you (or those around you) have issue with conflict. There could be a fear of retribution if they speak their minds or they don’t waste the effort trying to convince you of their perspective because you never see it their way.

Absence or abundance of conflict is not good. In either extreme, your company will not get the best solution or the solution will take too much time and cost to deliver.

Got conflict? Love to hear about it.

photo: shyald

Is Your IT Organization Telling "Fish Stories"?

mike.marshall@politicsofdesign.com (Mike Marshall) — Tue, 26 Jan 2010 14:36:00 +0000

The health industry tells me that I should eat more fish to increase my intake of omega-3 fatty acids (whatever those are). The environmental people tell me that factory fish farms are horrible polluters. The Discovery Channel tells me that the natural fisheries are over-fished and some species are dangerously close to being wiped-out. Or... maybe it's the other way around. I don't know. As a consumer of this information, it seems to me that I'm getting contradictory advice. Should I eat fish or no? Farm-raised or not? The answers are not simple. There are different angles to consider, and none of these sources give you the a complete picture.

As an IT department, we are giving our business partners advice from a variety of sources. The line developers advise the business users. The project managers do, too. The business analyst, the architect, the department managers all talk to the business partners and all try to provide helpful advice. Are your business partners getting consistent messages that considers all facets of the situation or are they confused by what seem to be contradictory information from different groups? I bet you know the answer...

Any IT effort is a balance of time, costs, and future sustainability. Each group within your IT services delivery should be concerned with all of these, but each tends to focus on one aspect more than the others. Sustainability is the focus of your support and architecture groups. Management has an eye on budgets. Project Managers are tuned into the project calendar and time lines. All these are important, but depending on the focus of the conversation and the group that is discussing it, one topic usually takes the lead.

Here's the thing. The topic that takes the lead cannot be the only thing we talk about. All conversations need to be about how these aspects are balanced. A project's value proposition is a zero-balance equation of all of these parts. For example, your team may deliver faster, but at a higher expense, or with reduced sustainability. High sustainability usually comes with higher short-term development costs and a longer delivery time frame. All of us have the responsibility to explain the gain and the expense to our business partners.

Each member of the IT organization needs to understand that every gain in one area leads to a cost in another. The full disclosure of all of these impacts needs to be made. This, then, allows your business partners to make well-considered decisions without being forced to reconcile conflicting information from different sources. Because if they have to do that, they may do what I do -- just skip the fish and order the chicken.

How have your organizations created a clear communication channel between your IT and your business? Tell us in the comments.

photo: mrjorgen

How to Predict the Future.

mike.marshall@politicsofdesign.com (Mike Marshall) — Tue, 19 Jan 2010 14:00:00 +0000

If you've been serving as an architect in your organization for very long, you are probably being asked a dozen times a week to predict the future. "When can we expect better performance from these queries?" "How many times will we re-use that component over the next 2-3 years?" "What will be the strategic direction of that application platform in 2010?"

With all the technology tools that we have at our disposal -- the software packages, the industry best practices, the arsenal of fully-baked design patterns -- there are still days when I sit in my office chair and wish for the two tools that I really need: a crystal ball and a lucky rabbit's foot. How in the world can we be expected to accurately predict the direction of our organization, the challenges that we will face, and the methods we'll use to overcome them? As architect's are we supposed to be clairvoyant? Are we supposed to be able to repeatedly and accurately predict the future? We are not only expected to do this, we actually can do it.

A recent Scott Berkun post had this quote in it:

"The words of the prophet are true because they are spoken, not the reverse. Prophecy is not witchcraft; it does not foretell the future but creates it." -- Reesa Grushka

Read that again, slowly, because it's something you need to remember. It tells you how to predict the future.

Visualize how you'd like the future to look...

The first step to predicting the future is for you to visualize what it should look like. Regardless of the subject matter, ask yourself how you would like it to look in the future. "How many times should we re-use that component over the next 2-3 years?" It's important to understand that as an architect, you may be the only person in the organization whose task it is to actually consider these questions. "What will the strategic direction of that application platform be in 2010?" What should it be? What makes the most sense to you? It's likely that you have the most comprehensive view of the situation and that you have even casually considered these topics in the past. You have some rough ideas and some sketchy plans. They just need to be formalized and thoroughly considered and validated. Develop your visualized "future state".

... then speak of it like it is a certainty.

Once you have created the future in your mind, then communicate it to all others. Tell it to everyone that will listen. But, do not communicate it as you are predicting it. Don't say "I expect that next year we will likely move to this new platform." Speak of it like it's a foregone conclusion, as in "When we complete our move to that new platform, we'll be in a great position for 2011." You can even treat this future state as nearly complete and talk about the next big effort like "Once this move to the new platform is complete, we'll be ready to start the next phase."

By following this formula, you'll start to realize that the large majority of the associates in your organization have actually been waiting for a "prophet" to lead them. They are ready to follow, and to create your future. Those few folks that will have the courage to question your vision and your certitude are actually confessing their own passion for leadership. They are your allies, and their future sight should be merged with yours. Once you have a combined view of the future, work together with the other leaders to reinforce its inevitability with the rest of the team.

Using this technique, not only will you be able to predict the future, you will have created it.

Go into work tomorrow and try this. Let me know how it goes.

photo: Isobel T

Successful Governance - Going Deep or Staying Shallow.

mike.marshall@politicsofdesign.com (Mike Marshall) — Tue, 12 Jan 2010 14:10:00 +0000

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.

Because an organization usually has fewer architects than it does developers, an architect's ability to deeply participate on every single project is challenged. The architect has a choice of applying himself in a shallow fashion across multiple projects or take a deeper approach on a few projects while letting others roll by.

The shallow approach means that the architect may participate in team meetings and act as "reviewer" on the design and code artifacts created by other members of the team. This risks his ability to catch critical issues early enough to modify their direction. What ends up in production may be different than what he thought was going to be implemented. This means subsequent projects may not be able to leverage capabilities as was expected.

The deeper approach means an architect embeds himself with a particular project team and takes on heavier assignments in the design phase. The architect is much more of a creator of artifacts than a reviewer. The risk to this approach is that an architect is focused on only a few projects, and he has no time for oversight of other critical projects that are going on simultaneously.

Either approach has pitfalls that can cause your governance efforts to fail. You can use both approaches provided that you apply a few techniques to maximize your governance impact. Here are a few ideas...

Triage...
Remember, one size does not fit all. As projects come in, be sure to triage them to understand which are particularly significant to your architecture team. Architects should be deeply involved with these project to ensure that upon completion, the foundations are built for the next projects to reuse. Projects that are not architecturally significant can be turned loose with only some initial direction and periodic meeting participation.

Divulge...
Every project should get an assigned architect, but that architect must clearly state his intended level of involvement in the kickoff meeting. Establishing the project team's expectations as to what the architect will be (and won't be) delivering is crucial to the project's success. This avoids the confusion that arises when an architect's involvement varies from project to project.

Leverage...
If there are too many significant projects for your architecture team to deeply participate in them all, then you need more architects. Sure you could hire them, but a better approach might be to grow them. Take another look at the "deep" project team members. Is there a developer or business analyst on the team who could assume the role of architect with some oversight? Tap them, leverage them, and help them grow into that role. This is a great "try before you buy" type of succession planning.

Engage...
Playing a deeper role alongside your project teams will let the other team members know that you assume full responsibility for the end product. Too often, the real project workers are instructed or managed from a distance. The people putting constraints on the builders are not quite stepping up to take on the accountability for their direction. Deeper involvement will let your team members know that you are putting real "skin in the game" on the project. This improves teamwork and communication with the architecture group.

Are you wading in the shallows or diving in the deep end?

photo: crankbaitcentral.com

Increase Customer Satisfaction with Diversity

mike.marshall@politicsofdesign.com (Mike Marshall) — Tue, 05 Jan 2010 14:30:00 +0000

I was speaking with a software vendor this week and he said something that made me stop and think. He said, "Diversity in your workforce is a big contributor to happy customers."

Architecture groups are usually small, and made of a few members with some stronger analysis skill sets. In a small group like that, when you start to get overloaded with work, it's easy to think, "If we just had another guy like Ted..." or "If I could just clone Susan..." Under this mindset, all too often, an architecture group can fall into a trap where all the personnel are very similar - same approaches, same backgrounds, or even same age. This can feel comfortable, but it may be holding back your relationships with other project team members. It may be leaving some of your internal customers feeling uncomfortable.

I understand that diversity in any group is a good thing. Different people with different backgrounds develop unique solutions to a problem. The diversity can breed innovation, and the cross-pollination of skills can build a stronger group as a whole. There are plenty of other well-documented angles on why a diverse workforce is better, but I've never tied the concept directly to customer satisfaction.

In this case, the vendor was speaking about circumstances where people often like to work with similar types of people. Birds of a feather will flock together, if you will. An extroverted developer may like it when they have an extroverted architect. Business analysts with a military background may interact more easily with an architect who has the same. A project manager prefers instant messages to phone calls - and appreciates an architect who is a "bing!" away. Working with a compatible architect can make the customer's experience more pleasurable and improve his satisfaction.

The point is that if you have a diverse set of architects, you are more likely to have one that can easily relate to a member of the project team. This similarity helps to promote a better working relationship between the team at large and your architects. Anything that leads to better communications and understandings on the project team is well worth the effort. So next time, you put on a new architecture team member think about picking someone who can bring more diversity to your organization. Your customer's will thank you for it.

photo: curious expeditions

Successful Governance - One Size Does Not Fit All

mike.marshall@politicsofdesign.com (Mike Marshall) — Sun, 27 Dec 2009 14:30:00 +0000

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"...

Categorization

We all accepted that "One size does not fit all". In other words, we needed some flexibility in our process to put small, non-strategic projects on the fast track through architecture review. However, we also understood that larger, architecturally-significant projects needed to be governed prior to the first expectation-setting conversation with its stakeholders. We instituted a lightweight scoring process where the project manager submitted the existing project concepts to our review board, and the review board quickly (in say, 20 minutes) designated the project as in one of four categories.

Category 1 projects are small with little need for architectural oversight. The working area is non-strategic or the expected changes are cosmetic or otherwise inconsequential. Examples of projects that fall into this category can be upgrades of existing tool sets or enhancements to smaller areas of the landscape deemed as not business-critical.

Category 2 projects are those with slightly more interesting changes that the board feels are significant. These projects are often in areas where a direction has been established and progress is on-going. The board may refer these projects to existing reference architectures or landscape maps, but specific guidance is left to the architecture member on the project team.

Category 3 projects are the ones that require significant oversight from the board. These projects will be discussed at length prior to any conceptual design being created. We ask that these projects come back to the board for this discussion, and the results are documented in the form of specific directives to the project team. The architecture member of the project team is then held accountable for compliance to these directives, and is responsible for bringing any variances back to the board for further discussion.

Category 4 is reserved for those "Wow!" projects. These are the ones that the board feels should be restructured because they are so broad and so wide-reaching that they intersect with multiple platforms and road maps. Usually, members of the board work closely with the project managers and stakeholders to break the project into a set of individually smaller efforts with interim way points (each with its own categorization).

An Accountable Team Member

To make sure that the board has an accountable project team member, a project architect sits on the team for EVERY project (even the Cat 1 projects). This person is responsible for being the eyes and ears of the review board, for ensuring that the project adheres to guidance, and makes sure that a project seeks direction from the board when appropriate. The project architect is selected from any of our internal architecture teams.

The value provided by this approach comes in two parts. First, the project team and its stakeholders can set early expectations as to the level of architecture team involvement in the project. Minor projects get minimal involvement. Major projects get significant involvement. More importantly, the project team and the architecture board open conversations at the inception of a project allowing both sides to work together toward a common result.

I'll post a few more things that we did to improve our service governance soon. In the meantime, if you have something that worked well, share it in the comments.

photo: taberandrew

How to Fail at Service Governance

mike.marshall@politicsofdesign.com (Mike Marshall) — Mon, 21 Dec 2009 14:30:00 +0000

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.

We failed because...

...We Viewed Governance as a Review Meeting
Our review board was established as project gate between the design and coding phases for a project. This architectural review happened once, and after the checkpoint was cleared there was no architectural oversight for the remainder of the project. This review was our one and only chance to govern the services in a project.

All design documents were created with little input from the architects, and the work focused more on creating the minimum required to pass a review rather than on the appropriate level of design for the project. Every project, regardless of size, would show up to a review with roughly the same amount of design documentation. Tiny projects would have 4 pages of design. Huge projects would have 4 1/2 pages of design. Even worse, the project's that did show up with decent documentation were scrutinized more heavily because they had something to scrutinize. This drove project teams even further towards the absolute minimum.

Governance cannot be a checkpoint. It must be a collaboration between architect and developer throughout the entire development life-cycle. It needs to start early in the process to help guide the services through their conceptual design and past their detailed design. When issues come up during coding, they need to be assessed against the early service strategies and re-worked to be the best fit possible.

...We Tried to Apply Governance After Commitments were Made.
The review was a traffic stop in the project immediately before coding began. Developers were in a place where they could see deadlines already approaching. Project managers may have already missed deadlines and were looking at possible budget overruns. The business had already been assured of a delivery date. Absolutely no one, other than the architects, wanted to slow down and re-discuss a design. If an architect felt so strongly about a design being wrong that he was willing to lay down on the tracks, more often than not, he was run over by the train.

Governance must be in place early in the process before there are concrete expectations (i.e., budgets, deadlines, and release dates) established. If everyone has a chance to understand where the strategic design guideposts exist at the beginning, they can all agree to them, and the team can move forward as a unified group. The design is understood, accepted, and protected by all.

...We Believed that Policy Alone Would Ensure Governance.
The review board would either pass or fail a project. When we failed a project, it was asked to re-work the design and reschedule a review. A project was not allowed to proceed without a good review. That is, except, when it had to proceed. The governance was protected only by policy, and the policy only had the influence and authority that was bestowed on the review board. Some projects, usually those managed responsibly, were slowed because they could be without risking delivery dates. The projects that were coming in over budget and late - were given exceptions. Again, we were more often penalizing well-managed projects and waiving bad projects through.

Governance that is applied inconsistently or intermittently is almost worse than no governance at all. Project teams that are singled out and held to higher standards begin to resent the process. Even when architecture is protected for a single project, the next ungoverned project can wreck the gains that were accomplished.

Consistent application of a governance process is the only way. Policies that are unevenly applied must be replaced with mechanics in the process that cannot be avoided. There must be a fair and authoritative enforcement mechanism in your governance processes.

Governance is one of those topics in Service Oriented Architecture that many experts say you absolutely need. Unfortunately, there is much less information to explain how it should be executed. Our organization learned many difficult lessons over the tenure of our Architecture Review Board. In upcoming posts, I will discuss our later, more successful, attempts at injecting governance into our software development processes.

Hopefully, you can benefit from our experiences. Tell us about your own experiences with SOA Governance. Have you succeeded or failed in this critical area? Share your experiences or thoughts in the comments.

photo:Rock Portrait Photography

Do Foxes Make You Angry?

mike.marshall@politicsofdesign.com (Mike Marshall) — Mon, 14 Dec 2009 01:31:00 +0000

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.

All too often, our reaction to these instances is to roll our eyes and shake our heads. There he goes, again. We get angry with the team member. We criticize them, condemn their behavior, and complain about them to other members of the team. Why can't they just get it right?! We resent their behavior even though it is exactly the same behavior that they always exhibit. In essence, we are angry with the fox after he's stolen yet another chicken. This isn't productive, and worse, it isn't very smart. The way to handle these situations is to change our approach to it.

Expect It

If a team member continually exhibits a behavior, you should know what to expect. Think about how you can adjust your plans to accomodate those behaviors. Don't schedule meetings early on Monday mornings if Sheila gets a late start to her week. If Henry's estimates are always short, pad them. If your boss is a surly skeptic, add time to the schedule so he can acclimate to your ideas.

Address It

If you really can't stand working around someone's bad habits, you can try to address it. You can try to speak with the person to bring the point to their attention. You may find out that from their perspective, they don't believe the behavior is a problem. In fact, they may believe that their behavior is appropriate for the situation. This makes addressing the situation even more difficult and time consuming. There are a number of things that must fall in line in order for the fox to change his behavior.

The fox needs to be made aware of the behavior.
The fox needs to believe that it is "bad" behavior.
The fox needs to believe that the bad behavior actually matters or has a significant effect.
Finally, the fox needs to have the desire and the ability to change.

Don't think that simply calling attention to the behavior will change it. You need to realize that this will involve a commitment on your part to help the person. After all, you are the one that wants a change. He's happy being a fox. Small changes might be made in the short term, but significant behavior changes can take years to take hold.

Just Get Over It

Nobody is perfect. People can improve naturally (albeit slower than we might like). Eventually, the person may modify the behavior on their own. You should understand, however, that the fox will probably always steal a chicken now and then. You should be ready for it and when it occurs... Smile, relax, and accept that the fox is just being a fox.

Think there are better ways to deal with the foxes in your organization? We'd like to hear them. Add it to the comments below.

Photo: Laurie Pink

Core Architect’s Values – Wrap up

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Fri, 11 Dec 2009 04:29:00 +0000

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?

I am not sure I have the answers to all of these questions (and I would like to hear what you think) but two thoughts come to mind:

First, I am not sure I can quantify the specific measurable effects of someone who has these values, but I can say seeing these values demonstrated in the people I have worked with made them more successful architects. On the flip side, I have seen architects who were significantly lacking in one or more of these areas and they struggled in influencing the direction of the solutions they were involved with. Unfortunately, I have also seen architects who *believe* they are demonstrating one of these values while they are really abusing it. E.g. mistaking stubbornness for tenacity or defensiveness for courage.

Second, these values do not define the entire person / architect. A successful architect must also be grounded and pragmatic. They must have a good functional understanding of the business they support, be internally motivated and need to possess a good bit of knowledge and experience in the technology they use. They also need to be an advocate for the systems they build, which was pointed out in a comment at the beginning of this series.

A final reflection on these values makes Tenacity and Sustainability stand out to me.

- Tenacity - is the most challenging to carry with you consistently throughout your career. There are many ups and downs in any career but consistently pushing for a balanced solution in the face of budget and time constraints can be difficult, especially in the economic times we currently face.

- Sustainability – is the linchpin value because it must be present in an architect. If an architect constantly builds “short” of expectations, I am not sure they will be architecting long, regardless if they are building software, or buildings or bridges.

These values are important regardless of your profession. For architects, they are essential. They can’t be bought and there are no classes to teach them. By nature or nurture, they need to be part of you.

If you perceive a certain value needs improvement, try modeling yourself after someone who exhibits this value. You may find you’re stronger in this area than you think. If not, focus on your strong values and fill any gaps in the areas you are weak with extra effort or a little help from someone who is strong in this area.

We’d like to hear your comments on any of the architect values posts.

Architect's Core Values: Curiosity - A Commitment to Life-long Learning

mike.marshall@politicsofdesign.com (Mike Marshall) — Mon, 07 Dec 2009 02:30:00 +0000

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.

Learners are the associates who take their lunch hour to dig through a few interesting articles. They write "Hello, world." programs as a hobby. They hear buzz on a blog somewhere, and go off to find other articles on the topic and maybe try out some free trials. Their project folders are strewn with half-baked code projects that got just far enough to illustrate an approach, but not far enough to be "done". They tinker. They learn.

Curiosity is the foundation that drives the learner, and for an architect, a commitment to life-long learning is a core value. An architect understands that what is the most correct approach to solve a problem today will not be the correct approach in the future. Technology evolves and the concerns of today's architect will give way to faster, cheaper, more intelligent technology of tomorrow. Unless he sharpens the saw, the architect may get stuck applying the old, ill-fitting solutions to new problems. An architect must display a genuine curiosity for new methods, practices, and technologies so that he can apply those to the problems that he'll face tomorrow.

Having experts in your organization is great. Have learners in your organization, and especially in the role of architect, is absolutely necessary if you expect your group to grow, evolve, and innovate for the future.

I'm curious. Do you agree?

photo: bdu

Architect's Core Values: Sustainability – the capacity to endure.

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Wed, 02 Dec 2009 13:21:00 +0000

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?

Architect's Core Values: Unity - Progressing, as one mind, toward a common endpoint

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Mon, 23 Nov 2009 04:22:00 +0000

Architect's Core Values: Unity - Progressing, as one mind, toward a common endpoint

Have you ever run in a 3-legged race? You and your tethered partner need to be in sync to complete the race let alone be competitive.

Now think about the average size of the project teams you’ve worked on and imagine trying to rapidly progress to any end point with members of this team tied to each other. Do you typically work with five person teams? Fifteen? Thirty!?!

My point is running a race by yourself is easy compared to when you need to cross the finish line as a team. However, building technical solutions is much more complex than just putting one foot in front of the other and requires multiple team members to deliver. The larger the team the larger the challenge especially considering the finish line may not be clearly in sight and sometimes moves in the middle of the race.  

Architects are not exclusively responsible for the team moving as one mind toward the common end point but they shoulder the lion’s share in many cases. An architect who holds unity as a value is naturally going to galvanize the team around a common solution and attempt to clarify the end-goal when the finish line is unclear.

More often than not, architects rely on influence in place of authority to establish vision for application and data landscapes. It doesn’t matter where the vision came from, or if it evolves based upon diverse team perspective but it is typically the architect who has to push for and clarify the vision and keep future solutions inline with the established direction. To be effective at influence the architect needs to bring people together under the common vision.

Building a unified team takes time, can’t be commissioned and may be impossible with some teams. An architect or anyone trying to establish some level of unity among the team members should consider these steps to build unity among their build team.

Embrace diversity:
Realize that diverse opinions should be leveraged as a way to quickly triangulate your approachs. Respect others’ opinions and leverage their diverse perspectives.

Outline options when roadblocks or impasses are met:
Solicit the team for a list of options, weigh out the pros and cost of each and pick the best one.

Leverage conflict:
Be comfortable with and use conflict as a quick way to determine which opinions move you toward your goal.

Maintaining Unity takes effort:
Watch out for the throw-it-over-the-wall mentality. This is a sign of a chink in group’s unity. 

If you have comments on how to improve the unity of your team, or have a different perspective, please post a comment.

Architect's Core Values: Tenacity – Never stop trying

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Tue, 17 Nov 2009 06:33:00 +0000

Architect's Core Values:
Tenacity – Never stop trying:
I can think of no better value to follow courage than tenacity. Courage moves someone from instinct to action but tenacity is the desire to keep on standing.

I have yet to see an IT shop of any size where influencing others was not a core part of an architect’s job. Influence brings compromise at times where, even though your 100% confident the approach you advocate is the best approach to take, the stakeholders will take a different path. Your stakeholders may even take on this Lucy-esque appearance when the next challenge arises and you line up to kick the ball…just one more time Charlie Brown! Loosing several battles in a row can deflate anyone.

Well, suck it up! It’s part of the gig and part of being an architect. You’re permitted to deal with temporary disappointment when the cards don’t fall the way you envisioned but you have to remember that success is measured in inches, not miles and by months or years, not days.

Acting in the best interest of the company and its systems is a delicate balancing act. Architects, like the development team, want to delight the business with the features they need when they need it but they also have to look further out and consider the sustainability of the system and anticipate future demands of the business.

Tenaciousness is required in all architects. Regardless of their area of focus, architects face significant time and cost challenges on solution delivery. Building it the architecturally sound way will frequently be prioritized below time to market and lower cost solutions. The reality is delivering the best solution for the business takes a balance of influences from project management, the delivery team AND the architecture team.

Architecture influence is a required element in ALL successful solutions. However, architecture influence generally isn’t the main ingredient and, in some rare cases, the solution will only contain trace amounts.

Tenacity is difficult to coach because there are no pre-described guidelines or formulaic equations to determine when standing resolute is a good idea but three guidelines are outlined below to help guide the development of this essential value.

1 - Use Logic - Don’t confuse tenacity for stubbornness:
A tenacious architect comes to a discussion, listens and advocates a sustainable approach even if this approach was bypassed previously. A stubborn architect advocates the same approach regardless of the differences in the current project and the last just because they seem similar. Architects should let pragmatism be their friend and use common sense to determine the degree of architectural influence that needs to be applied to the solution.

2 - Tenacity is NOT about who wins:
Listen carefully to problem-solving discussions. Are your architects and developers trying to deliver the best solution possible or are they trying to win the argument? Getting emotionally engaged in any discussion is easy if you are in the discussion and easy to spot if you are an observer. If you find you’re getting too emotionally engaged in a debate (or witness someone else too emotionally engaged) use some data or fact to diffuse the emotion and remain pragmatically centered.

3 - Pick your battles - Bend but don’t break:
If you’ve outlined some logical reasons why the architecturally sound approach will cost less over the long term and used some data from actual production situations to diffuse “red herring” attempts to win an emotional battle, you’ll need to take stock in your position. Is this a battle worth fighting? Worth escalation? If it is…push for the appropriate solution as hard as possible, build support with your management team but most importantly, understand your minimum success criteria so the solution can move forward without determent and if it does fall below the minimal success criteria, be prepared to articulate the tangible and intangible costs of doing so.

Business is not linear. One day you’re focusing on projects to gain market share, the next to improve operational efficiencies but your architectural values are part of your DNA.

Do you agree with this architectural value? Are there other guidelines you advocate?

photo: Tenacity

Architect's Core Values: Courage - standing up for what you believe.

mike.marshall@politicsofdesign.com (Mike Marshall) — Fri, 13 Nov 2009 04:05:00 +0000

Architect's Core Values:
Courage - standing up for what you believe.
It's word association time. If I say "Courage", you think what? Cowardly Lion? "Red Badge of..."? Well, I think "Software Architect".

At some time in their career every architect has experienced this scene:

The project team is meeting. Deadlines are looming and costs are building. The stakeholder wants to see progress, but there's an obstacle in the road and it's a big one. A decision has to be made and made well. This decision has far-reaching implications beyond this project. There is discussion and proposals are floated. There is the proposal to plug in a quick-fix; something quick and dirty. There's the proposal to short-circuit one of the primary design objectives. There's the proposal that defers the issue to the next project or release.

The group discusses the alternatives and starts to lean towards one of these "lesser solutions". At some point in the meeting, they might even all agree that if the situation were different - if we had more budget, more time, or more support from our executive management - we'd definitely attack the issue more strategically. They might agree that they want to address the obstacle with a well-conceived, sound, and sustainable design, but given the situation today they just need to patch it and move on.

"It's not a great solution, but we have to do what we have to do, right? Is everyone agreed?"

Heads around the table start to nod. Some people nod because they believe that it's the right thing to do. Some people nod because they are undecided, but if everyone else agrees, it must be a good answer. Some people nod because they nod at everything - their career is almost defined by "nodding".

But the architect isn't quite ready to nod yet. She's still thinking about that sound and sustainable design. She's not quite ready to make the trade-off, and just when everyone else is packing up their stuff preparing to end the meeting, her hand goes up, and she says, "Hang on a second, I'm not bought in."

The courage to stand up in the face of stakeholders, project team members, and executive management and defend a design approach is a core value for an architect. Architects who have invested the time to think through a particular problem and design a solid solution are not easily argued off their position. Those that hold their ground in these circumstances and can calmly articulate their views in the face of this pressure are the good ones.

If this scene is familiar to you, it really doesn't matter which seat in that meeting you're sitting in. Your title might be the project manager, the developer, the business analyst, or even the end user. But at that moment, if you are holding your hand up to defend a more sound and sustainable approach - than you're playing the role of an architect and exhibiting one of the architect's core values.

Is COURAGE on your list of core values of an architect? Please join us and help establish the Architect’s Core Values.

photo: simpologist

Architect's Core Values: Impact – the desire to create something great.

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Mon, 09 Nov 2009 05:07:00 +0000

Architect's Core Values:
Impact – the desire to create something great:
Delivering something that’s used by the business is good…but delivering something that’s a game-changer is deeply satisfying. Architects are driven by the desire to create efficient, highly effective, long lasting solutions. Substantive initiatives don’t need to be in the coolest business area or developed in the latest technology but the commonalities these initiatives share are: the significant need of the business, complexity of the challenge and the criticality of getting it right. These solutions are the first ones to come out when sharing some battle scars with some current/former colleagues.

Substantive initiatives don’t come along every day but when they do, your impact players run toward them. It’s the challenge combined with the ability to influence the way their company does business that drives them in this direction. It’s the satisfaction that comes from knowing they made an impact.

Is IMPACT something that drives you? Something that drives your staff? Please join me and help establish the Architect’s Core Values. What do you think drives the determination of an architect?

photo: Jeff EngelHardt

Architect's Core Values

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Tue, 03 Nov 2009 05:50:00 +0000

What is your most pervasive work-related thought on your commutes to work? Is it what you didn’t get done the day before? Your boss? The bewilderment on why simple challenges turn into multiple meetings and bureaucracy? Do you get amped up thinking about what the day holds or is it just another day in the office? Take fifteen seconds and really think about it…

We’re living in interesting times (if you consider turbulence interesting) and I’ve found myself contemplating what makes me and the people around me “tick”. We’re all faced with increasing challenges at work but I often find my determination amplify as I go to work in the morning. Almost like prepping for a competitive sport: determining what our game plan is or establishing success criteria for the day.

After some contemplation, I believe it is my core architectural values that drive my behavior and the behavior of my architect staff and peers. Our core values are our guidepost. You might be thinking: “Great! He finally figured out the basic fact that values drive behavior”. If so, you might be overlooking the single most important element that galvanizes and motivates your team.

Core values are the reason we bring our “a-game” each day. The reason we fight day after day on the same issues such as standards or patterns. The reason we resist the urge to accept the path of least resistance when we’re sure it jeopardizes future enhancements. The reason we strive to balance the time, cost and quality of solutions with an eye on the horizon.

I believe great architects share similar values. Values that bind us together and keep us on track. Values that are as much a part of us as the color of our hair or the stride in our step.

Please join me and help establish the Architect’s Core Values. I'll reveal my list over the next few posts. More importantly, I would love to see what you think drives us to give 110% each and every day.

Values:
- Impact: the desire to create something great.

photo: IdeaMill

7 Helpful "Legacy Programmer Boss" Tips

mike.marshall@politicsofdesign.com (Mike Marshall) — Sat, 24 Oct 2009 19:00:00 +0000

I've enjoyed reading some the the Spolsky-generated articles recently, but I was snagged by the viewpoints put forth by Daniel Auger in his post "The State of Spolsky or How I Learned to Ignore my Legacy Programmer Boss". That post was furthered by Krishna over at Thought Clusters in "The Legacy Programmer Boss".

Daniel Auger says:

The Legacy Programmer Boss is the manager who had a successful programming career in the past but sees many modern concepts as language baubles, academics, and anti-patterns because they are out of the loop. The fact that they once had a high degree of expertise gives them confidence in making mis-judgements.

I wanted to focus on this concept because I believe that every programmer will eventually become a "Legacy Programmer Boss" or a "Legacy Programmer Architect". It is almost universal that this phenomenon will occur in older,experienced software professionals. It is also guaranteed that every programmer will at some point have a legacy boss lead his team. It only helps us all if we can communicate better. When you, the young turk, run into this surly skeptic, try to remember these 7 tips to help work together...

1. Have Respect

First -- and it's first because at this point in my own career, I more resemble the surly skeptic than the young turk -- show some respect! That legacy programmer has some deep experience, and has written some good stuff. He's seen many a revolutionary concept that doesn't quite deliver or evaporates entirely. So, he has earned the right to be a little skeptical. Don't make the mistake of thinking because he's never coded in the latest tools that he can't possibly understand the concepts inside of them. Concepts do not often change dramatically across incremental technologies.

2. Just Explain It

Whether the idea is a new pattern, approach, or construct, just sit down with your boss and explain it to him. Don't expect him to read the documentation and don't send him links to long-winded technical articles. He's not going to fish for himself. It's not his job to be up to date on the latest and greatest coding technique. That's your job. He will grasp the important concepts soon enough, and he does not need the deep knowledge that you do.

3. Find Familiar Ground

Work with him to find a similar, more familiar concept that was commonly used in the past. Compare and contrast the two concepts. Talk, first, about how they are similar, and then how the new way is an even better extension. As I said before, concepts don't often change, so there are usually constructs or techniques in the not-so-distant past that you both know well that are useful analogies. If those are hard to find, is there a real world metaphor that is useful or a comparison to the mechanical world?

4. Bring the Value

Work from the real business value of the advancement. How does this new stuff help your organization in hours saved, bugs avoided, or tests passed. The legacy programmer boss is today more likely to be budget minded and target driven. Make sure the thing that your pitching provides those values. If you can't explain the business value in those terms, you better ask yourself why you are in his office. Because if you don't, he surely will.

5. Be Honest

Be realistic with yourself. You are excited about a brand new technique. The technique is fresh, new, and fun, but won't immediately turn your company's business model on its head. Be aware that because you are offering it up, you might be personally invested. Accept that this at least has a small possibility of not delivering what you expect. Don't oversell it or embellish the advantages. You definitely don't want to risk being associated with what turns out to be some vendor's snake oil.

6. Bring a Plan

Understand how you will introduce the new technology into the landscape. If a big bang approach is your only option, you probably won't find the boss willing to take that risk. Start with a smaller proof of concept, and build from there. In your plan, explain what metrics you are going to track and how they are going to be measured. Show him that you're willing to let the results speak for themselves.

7. Make him look good

Understand that there are a number of priority items that he's trying to address that have been handed to him by his own boss. Introducing your new code construct is probably not one of those. If possible, understand what his objectives are and explain how this new technique can help him reach those objectives. Use these objectives when you're talking about (#4) the value and (#6) the plan.

Follow these tips and you'll find that partnering with your legacy programmer boss can bring even larger value to your organization by understanding both the old and new technologies.

Do you have experiences with a Legacy Programmer Boss of your own? Share them in the comments below.

photo: monkeyc.net

Right-size your SOA

mike.alvarez@politicsofdesign.com (Mike Alvarez) — Tue, 20 Oct 2009 12:05:00 +0000

I’m so glad SOA is dead because we can move forward without the hype-anchor weighing us down, and confusing those who probably shouldn’t be muttering ‘SOA’ in the first place. This means we’ve finally crested the peak of overinflated expectations and trudged our way through the valley of despair and shaken the shackles of a new approach...and can get on with business!

Service oriented architectures were around long before SOA became a cool buzzword. A service oriented architecture is still a viable approach, but you need to right-size it for your organization. Here are some items to ponder regardless if you are just starting out, or have a mature SOA in place.

Don’t be a victim of accidental SOA architecture:
Have some idea of where you want to end up before starting your SOA journey. If you’ve already started you still need to determine your ultimate end-state. Too many companies embark on this journey before understanding the true costs, what role governance plays, what packaged apps are required along the way, and how long they are we willing to take before getting to their destination. This lack of planning is analogous to uprooting the family, committing to a new job in an unknown location just because someone showed up at your house and handed you keys to an awesome new sports car...you don’t know were you’re going or when you are going to get there...but you’re making great time!!!

Find (or define) an SOA maturity model:
Creating a roadmap or referencing an SOA maturity model will help you determine the ultimate end-state of your SOA. Check Google for a maturity models that fits your needs. If you don’t like what you see (too vendor specific or too complex) create your own! The real value is in the conversation among the various impacted parties and the confirmation of your end-state including how long it could take to get there.

SOA Maturity model - items to consider:
1. Not every company needs to achieve the highest maturity level. Pick the level appropriate for your company.
2. Advancement is not linear. You could spend years in one phase then blow through another in a matter of months.
3. The gap between phases could be larger than you realize. It could take substantial investment to get to the next level. Be patient...see #2.

Consider your environment - Size matters:
One of the most important drivers to right-sizing SOA is your environment. Size matters when it comes to getting traction with an SOA approach. If you have large disparate legacy systems, or your company has grown through large merger / acquisition then you have large challenges to solve and your company is more likely to undertake large investment to support these systems or solve these problems which will move you up your maturity model more rapidly.

On the other hand, small and medium businesses need to carefully choose which SOA stepping stone to chose first. Many vendors would tell you that you need a runtime governance tool to monitor service performance, determine the services largest consumers, etc. However, an investment of this size early in the life cycle could delay perceived business benefit and kill your SOA initiative before in becomes an integral part of your landscape.

Also consider your business model. Are some areas of your business more stable and consistent than others? You may want to target these for some of your first services rather than an area in a great deal of flux.

SOA does have its place as the core architecture that supports your business but it is not something you can buy off the shelf and plug in. It will not be successful without significant architecture influence on how to right-size it for your organization.

One final note on selling your next set of SOA investments is...don’t mention SOA. Focus on the business drivers for the need and how SOA enables the business. Focus on the problems it solves. SOA is the means to the end, not the end itself.

Has SOA been successful in your organization? What were some of your largest stumbling blocks? Bring the comments! Good or bad, I’d love to hear them!

photo: Mojocesa

Prove that Service Oriented Architecture has an ROI

mike.marshall@politicsofdesign.com (Mike Marshall) — Sun, 11 Oct 2009 01:59:00 +0000

We have all been searching for a concrete and measurable return on our SOA investments. We've searched the internet and read case study after case study. Industry experts and SOA pundits tell us that it's there. We know in our hearts that it's there. However, we've all been in the meetings where business stakeholders and executives are not satisfied with what we believe or what the experts say. They want us to prove Service Oriented Architecture has a definitive and measurable ROI. It's an elusive problem. How do we prove to them (and to ourselves) that the proposed architecture can pay for itself?

Projected ROI is a Promise

When we are justifying a proposed architectural investment, we often project how the new design initiative will pay for itself over the coming months/years. This return is based on future projects leveraging the initiative's capabilities or reusing the foundational components. This forward-looking ROI is a prediction and it is based on the likelihood of those future projects being executed and the solution being implemented to maximize the return. In short, the projected ROI is a promise.

Those stakeholders have heard the promises before and have seen them broken, too. They've seen directions change, projects canceled or implemented in ways that didn't take advantage of earlier foundations. When the promise didn't come true, the original design initiative was called out as a wasted investment and written down as a failure. When things fall short of expectations, they are remembered. These instances add up to a credibility gap that makes creating a forward-looking ROI picture difficult.

In order to combat that credibility gap, you have to call out and write down the instances where you actually experienced good returns on architectural investments. Often, these wins are overlooked because they were expected results. Meeting expectations is never quite as memorable in management's eyes as are the projects that fall short.

Realized ROI Builds Credibility

The key to building this backward-looking ROI picture is to collect hard data over a number of months that is directly related to your own business. These form your own case study where the details are easily understood by your managers. The familiarity of this data adds credibility to your arguments for future efforts.

Identify the 3-5 architectural design initiatives that you have implemented over the past 18-24 months. These may be large efforts that built out heavy frameworks, or it may be smaller, simpler components that have been re-used. The size of the initiative is a function of your organizational size and its tolerance for large initiatives. Even in the most frugal environment, these examples can be found. You just have to turn over some large stones to find them. Record these initiatives along with the date that they were implemented and their implementation costs.

Second, identify subsequent efforts that received some benefit from these original design initiatives. These may come in the form of maintenance and support changes, secondary phases of the same project, or unrelated projects that re-used the original initiative. Record these benefits alongside the original initiative. Lastly, record the savings that were gained from the reuse of the original component.

Identifying the quantifiable costs and savings of the two respective efforts is the most critical task, and also the most difficult. The cost of the original initiative may be wrapped up inside a much larger project. The savings gained by the secondary effort might be hard to definitively quantify. You need to invest some effort into these numbers because you can expect them to be scrutinized later on. No matter the difficulty, you and your teams must settle on the numbers and be able to defend them when asked.

This process of identifying new design initiatives and recording actual benefits gained by subsequent implementations needs to be added into your development lifecycle. Schedule a meeting around each release cycle where development teams come to describe and quantify the initiatives and the benefits. This activity provides the hard data that is relevant and the picture that it draws is tangible.

Only by carefully recording your backward-looking wins can you support your forward-looking predictions from a position of high credibility and stakeholder trust.

Have you had an experience where you established a good return on your SOA investment? Share it with us in the comments below.

Infect Development Groups with the Adoption Virus

noreply@blogger.com (Mike Marshall) — Fri, 02 Oct 2009 23:47:00 +0000

The situation is common. Adoption of the new architecture has been slow (or non-existent). If you are to hit your roll-out targets, you have to find a way to accelerate it. But for some reason, no one seems to be picking up your latest advancement and rushing headlong into a new type of implementation. At the same time, no one provides any significant reasons for this reluctance. The feedback does not call out weaknesses in your design. In fact, the little feedback you've received was positive. It's just that they choose to roll-out new functionality using the old, tried and true approach. Since you have spent the majority of your time nurturing this new architecture, you are personally invested. Your frustration starts to build as you see opportunities missed and weeks pass. After some time, it begins to feel as if the reluctance is just an unspoken, negative judgment of the new stuff; of your new stuff.

In fact, the real reasons that the adoption is slow has very little to do with the architecture at all. The slowness is understandable and you really should have predicted it.

The choice of which architecture to implement can be made weeks before the design phase of a project even begins. It is made when the development team is first asked to size the effort. Is it small, medium, or large? These early sizing estimates carry with them many unspoken assumptions. One of those is the inherent assumption that the new solution is built using the current architecture methods. the development team bases their sizing estimate on their experience from the past, and that experience was with the old stuff. So, the architectural status quo is inherently selected from the onset of the project. As the project gets further down its time line, this direction puts down roots and is more difficult to change.

Undeterred, you keep selling the new architecture as the second coming of sliced bread. The project has started to roll, so a plan is taking shape. There are already dates. The new way sounds good, but developers can already see schedule risk. Has this new stuff been used before? Is it fully baked? Can it fit within the original estimates? The most common developer concern is whether the architect will stand beside him and be accountable for any cost and schedule overruns. Can it (or you) be trusted?

The developer will start to balance these risks against the benefits to them. Unfortunately, new architectures do not always benefit the developer. The new designs may improve a dozen areas of the system, but ask the developer to implement more complicated code to realize those benefits. When developers don't see the value first hand, they may start to question the direction again. The newness of the approach can cause misunderstandings, frustrations, and re-work. The new architecture starts to get labeled as more difficult to use, slower to implement, or providing no real improvement over the existing approach.

A better way to come at this situation is to introduce this change from within the development group.

To begin this process, you must identify the architecture change leaders in the development group. Every group has one of these. This person is passionate about finding better ways to do things and willing to share those ideas with the group. They attend conferences, read blogs, and challenge you on your ideas. When you ask where they expect to be in five years, often their answer is "In your role". These are the junior architects, but they are still in the developer ranks, and that is important because other developers see them as one of their own.

The second step is to truly inform this change leader about the new architecture. If you have picked the right change leader, they will be excited to understand it better. Go over the primary benefits that the new design provides and explain why those are important from a business viewpoint. Explain all aspects and be honest about the trade-offs that are made in the design. Make sure that you cover the common objections that a developer might have to the new design, since they will likely hear them, too.

You also need to listen carefully to what this person thinks about the new architecture. Consider carefully whether any of their suggestions could and should be implemented. Any new system is not perfect, and a sincere consideration of suggested improvements will foster teamwork between you and the change leader. They may have a better appreciation for how the architecture fits into other areas like configuration management or deployment administration.

Having done all this, you are then left with a much more willing participant in your roll-out. They will be eager to apply the technology since they understand the benefits better. They will be more prepared to create the best implementation, and will keep you informed as to their progress without direct oversight from you. If issues pop up, they will work closely with you to resolve them not only for the project at hand, but for the benefit of the architecture itself. They have been transformed into a stakeholder and will carry this attitude back to the development group. There, they are seen as a trusted resource with highly regarded insights about the new stuff. They become your architecture's primary evangelist and knockdown the obstacles standing in the way of its adoption. Suddenly your latest architecture starts to find new life. You have infected your development group with an "adoption virus".