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

Who's managing your career?

Posted by Mike Alvarez On Sunday, September 27, 2009 0 comments

I don't know about you but, 2008/2009 was a period of great introspection and stock-taking for me. The financial, standard of living and career aspects of my life were under a microscope. Most companies downsized and everyone cut cost. During this time, I re-learned the lesson that job security is tied to anticipated future performance. Gone are the days of earning a spot in a company because of seniority, past performance or position. All of the chaos around me reaffirmed it was a time to get strong and manage the different aspects of my career.

I worked through this experience with one resounding truth: if I wanted to maximize the value I can bring to my company or any company, I had to take the wheel. No one was going to hand me the roadmap to a more successful me. This is true of many senior technology and management personnel. The higher you climb the harder it is to keep your edge. YOU need to be accountable for your "professional equity".


During a conversation with a colleague I started thinking about this in terms of five progressive steps.

5 steps to enhance your professional equity:

1. Sounds simple but, excel at your current job function. If you write software, write damn good software and keep up with technology trends. If you're a Project Manager, get PMI certified, find the 10 biggest pain points of the business area you typically support. You're going to be the best at determining what you need for professional growth. Make a list, rank it and pick the top 5. Most of us don't need help with the list, we need time to get it done.


2. Build your professional network. Find like-minded folk and build relationships. Join a social networking group in your local area. Get out and talk to peers face to face. I'm not talking about interacting with friends during your nightly gaming sessions or participating in online social networks. Find new professionals in your space and meet them for coffee or lunch. Why? Compare notes. Ask them what excelling as an IT Architect means to them.



3. Since you're reading The Politics of Design blog I assume you've landed or quickly accelerated to this step. Find an opportunity to combine #1 and #2 so that you can contribute outside your current role or company. This is a crucial step that will test your mettle. Think broad! It could be applying your leadership skills to your church, planning skills to a non-profit organization or applying your technical skills for your own financial benefit. This step is all about walking the talk. Be patient and persistent because it could take you 12 months or more to achieve this step.


4. Now that you've proven your prowess, promote yourself. Blog, publish, speak, participate, engage and learn. If you leverage your network in #2 and the result from #3, you'll be swimming in opportunities. You may have no idea how to do this when you start your journey but somewhere during step #3 a light bulb should go off.


5. The final step is to learn or leap. At some point every company needs to "take it to the next level" or lose market share. The same goes for you. Left unchecked, your value and security will decrease over time because job security is tied to anticipated future performance. You can increase your value with your current employer by learning. Start at step #1 with something new and expand your skill portfolio. Hopefully you work for a company where adding skills is possible. If not, you might have to "leap" and find an opportunity where you can continue to grow. Either way, you're reached the point in the S-Curve (or Sigmoid Curve) where you need to consider your next step. Contemplating this next step may keep you up at night but as General Eric Shinseki (retired Chief of Staff, U. S. Army) said: "If you don't like change, you'll like irrelevance even less".

It seems fitting the career management hierarchy resembles Maslow's Hierarchy Of Needs. The further up the pyramid you move the more you focus on identity and purpose and less about job security. The less you apply yourself and the more you resist change the more you are concerned about putting food on the table.


You might be concerned about the "external" focus of this approach. Don't misinterpret this as a "up and out" approach!! I can only see positive returns on this investment. If you are managing your career in this manner then you are (1) good at what you do, (2 & 3) have taken initiative to not only talk about what you are passionate about as a professional but practice it and (4) received some level of validation that the skills and talent you have developed are valuable. Who wouldn't want to work on a team with these attributes? Level 5 is not walking out the door but rather achieving a level of understanding and accomplishment you can leverage in your next iteration.

READ MORE >
Tags:

Reuse and Win the Clone Wars

Posted by Mike Marshall On Friday, September 18, 2009 0 comments

When we have the opportunity to reuse an existing component, but neglect to do so, a near copy of the original or a "clone component" is born. The cost of this missed opportunity is usually just counted as the cost to build the new clone1 . But this price is only the first one that we pay when we don't make an effort to reuse. There are even greater costs growing in the shadows of this missed opportunity. To understand these clone costs, we have to look at how we let them grow.

The system starts off with a simple, original component. Soon, an extension arrives where the original component should be refactored for reuse, but in our haste and shortsightedness, we create a clone instead. This is the first mistake, but it is usually not a single occurrence. If one new extension emerged, you can bet there will be another, and when the next one arrives, there are now two components to be refactored (the original and the clone). This makes the refactoring option even less appealing. Further, avoiding the reuse once has made it more emotionally acceptable to avoid it again. Sadly, Once we have created two clones of the original component, we have an even bigger problem. We now have a "pattern". This pattern only serves to further lower the barrier for more clones each of which increments the total cost of refactoring the system. How large can this problem grow? In one extreme case, I have seen cases where over 45 clones of a single, simple component were identified in a system.

So the cost of these missed reuse opportunities escalates to the total cost of all the clones plus the refactoring cost that we must take on to break the cycle. In this extreme case, the cost of the refactoring could not be justified. The refactoring cost was so high (at a multiplier of 45), that we could not show a return signficant enough to offset it. The cost of refactoring the system had actually exceeded the value proposition of the well-formed system itself.

If allowed to reach this extreme, another cost becomes apparent and this one becomes the most difficult to accept. At this point, any desired system enhancement may well require changes to all the components including the original and the clones. The total cost of these changes can easily outpace the business case that accompanies the enhancement. The result is that even simple changes in the system can be prohibited by overly inflated development costs. In the end, we are left with a system that can neither be refactored nor enhanced. It can only be maintained. The choice to avoid reusing components has resulted in a system that is a barrier to business innovation rather than an enabler, and that is a price that no one can accept for long.

The key to preventing uncontrolled cloning is to break the cycle as early as possible. In some cases, it may not be possible to stop the first clone. Often, the first extension is viewed as a "pilot" or a "test case" by the stakeholder, and in those cases, there can be reluctance to invest in reworking the original component. This may be fair, however, the extension must immediately be identified as a clone to both the stakeholders, and it should be documented as a clone to alert future developers. After this, a subsequent request to further extend the system must be acknowledged as a pattern. At that point, the original component and the clone must be refactored into a reusable, generalized component. If the stakeholder pushes back on this refactoring, cite the pattern and show them that this cycle will repeat itself unless it is halted. If they still push back, bring all of your architectural governance forces to bear to defend your systems against an attack of the clones.

________
1 The "reuse cost" of a clone is sometimes cited as 80% of its total build costs. Since reuse is not completely free, 20% of the original build costs seems a reasonable estimate for adaptation and reuse of the original component.

READ MORE >
Tags: ,

The Politics of Design

Posted by Mike Marshall On Monday, September 14, 2009 0 comments

The Politics of Design is dedicated to the challenges and triumphs of software architecture advancement within the IT organization. We believe that architecture is truly a servant to two masters.

We are all software creators, and as a profession, our careers are filled with successful designs, frameworks and projects. Our resumes contain hundreds of acronyms. We have savored the chance to slay mission-critical dragons. We have witnessed the birth and rebirth of relevant techniques and approaches. So when we are asked to create a new solution, we get right to work.

We discover and analyze and gather around tables to discuss how to model real-world complexities inside a conceptual system. We move forward with our design keeping one eye on successful approaches of the past and another on the latest best practices. We review our approach with groups of stakeholders. We are confident that we have prescribed the right solution, but as complex as the task is, designing the right solution may be the easy part.

While we were designing, the business was exploring their own questions about maximizing profits and improving efficiencies. The business rate of change outpaces the flexibility of the IT organization and its systems. Upon delivery of the design, the debate over value propositions and time to market begins anew. The prescribed solution seems more expensive and the delivery date more distant. Inevitably, the seeds of doubt start to grow.

Enter the status quo, aversion to change, and organizational resistance. The momentum slows. The ideas are reconsidered. The progress becomes imperceptible. At some point, the technical details matter less than reaffirming executive sponsorship and convincing everyone that the initiative remains truly valuable. Too often, the "right thing to do" ends up capitulating to the "way that it's always been done".

This outcome should be neither resented nor unexpected. It is the status quo. Change is difficult for us individually. Change within a team is even more so. In today's IT organization, our most significant architectural challenges are equal parts technology and leadership, sales as much as structure, and influence alongside innovation. Organizational dynamics and change management are something to be embraced as part of the overall architectural challenge.

Architectural advancement involves a complicated confluence of human and technological interaction. We hope to address both sides of this complex equation with these posts. We will focus a portion of our time discussing the architectural approaches, ideas, and strategies we have employed. We will focus a portion of our time discussing the institutional behaviors and the methods we find effective in advancing our ideas among them. In this blog, we will cover both architectural design and organizational politics.

Welcome to The Politics of Design.

READ MORE >
Tags: , ,