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

  • Autumn Road

Who owns software design?

Posted by Mike Alvarez On Tuesday, March 16, 2010 What do you think?

Seems like a simple question…but many valid opinions have elicited many fiery debates. Help me provide some answers by reacting to my perspective below. I decomposed design into 3 parts: A). Definition. B). Major inputs into design. C). Who owns it.

A: Definition of Design:
The act of design is not unique to software. It exists in many areas of our lives. There are many definitions but here is one I think most of us could agree on: “Design is an activity that translates an idea into a blueprint for something useful, whether it's a car, a building…a service or a process.” For an IT shop, the “something useful” is software, the “blueprint” is the design and the “idea” is the requirement(s).

B: Major perspectives/influences into Design:
Before we tackle who “owns” it, let’s think about who needs to be around the table and the perspectives they bring. I’d argue there are 4 key perspectives that need to be considered in order to be successful in the vast majority of design decisions.
1. Immediate business need / idea.
2. Condition of target legacy system.
3. Longer-term solution target.
4. Resource constraints (time, money, human resource capacity).


Architecture or Arrogance?

Posted by Mike Marshall On Tuesday, March 09, 2010 What do you think?
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?

Fun size your design

Posted by Mike Alvarez On Tuesday, March 02, 2010 1 Comment

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.