Technology organizations have hundreds of case studies waiting to happen because they are one big paradox. They love process until they don't. They want to build sustainable solutions unless they need it quick and dirty. Every effort is like one big push, pull, tug rugby match.

As architects, we seek a balance in this tug-o-war between advancement of architectural best practices and the inevitable restrictions of resources and cultural inertia.

Welcome to the Politics of Design...

Is Your IT Organization Telling "Fish Stories"?

Posted by Mike Marshall On Tuesday, January 26, 2010 0 comments
Is Your IT Organization Telling Fish Stories?
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...


How to Predict the Future.

Posted by Mike Marshall On Tuesday, January 19, 2010 0 comments

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.

Successful Governance - Going Deep or Staying Shallow.

Posted by Mike Marshall On Tuesday, January 12, 2010 0 comments
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...

Increase Customer Satisfaction with Diversity

Posted by Mike Marshall On Tuesday, January 05, 2010 0 comments
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.