Time as a victim, change as a child

There are things that rattle around inside of projects things that we don’t see. There are variables that people never address.

  • Is this the right project
  • Are we doing this at the right time
  • Is this really what we need
  • Did we plan for the right amount of change
  • Is there enough time in the plan to get this done

The last two are the funny ones. Time as a victim of the project planning process. why is it that no matter how many times you do something you are often off in terms of the time it requires?

Why is change such a huge variable in one project, then do the same project in another place and change doesn’t matter at all.

It is the wonder of software architecture.

.doc

The path to the accidental enterprise architecture

I have a number of friends who are in the space Enterprise Architect. They are brilliant people who are able to map huge business problems to various solutions within an organization and have everything work together.

But in most cases the companies I visit don’t have an EA team, or if they do they don’t have the output of that team (an enterprise architecture).

Why is that?

The smartest people in the profession i know call themselves Enterprise Architects. They live and breath taking business process and improving it through the use of technology and other solutions.

  • They use Norton-Kaplan maps to determine what they need to consider.
  • They build huge blue ocean strategies designed to carry the business into the realm of non-competition

So why the disconnect?

Or am I asking for too much?

.Doc

Development as an extension of the architecture

I know a large number of developers (and have for many years). I find that most developers are structured analytical people who do a great job of thinking through specific problems in front of them (or around them, near them etc). In fact the one’s I’ve worked with are so good, as an Architect I often feel like I can just disengage and let them do what they need to do.

So the question is, with good developers is development an extension of the architecture itself?

It seems like that is reality of the world but you never know.

In some development organizations they don’t take that approach – they focus on having a management structure around the developers so that they focus on coding not moving the solution forward.

Perhaps that is the reality of the world but it seems funny to me. If you hire smart people and set them on your problems, in theory they will be able to solve them in time. If you lock them in a room then in the end you will get exactly what you asked for rather than a solution to the problem.

.doc

If, and when

If is an amazing word in the architectural space. If is a portent of things to come that are built into a solution and yet may be an extra benefit.

When on the other hand is a known entity – something we know will come from this solution we have deployed.

Together they are the promise of a solution. When is the known benefits that we were seeking in deploying the solution. If represents the future state additions that we may yet gain with this solution.

For example wifi may originally have allowed people to work in conference rooms and places other than their desk as a when. The IF would be the ability to have separate wifi networks for contractors and other temporary employees that are segmented from the rest of the network.

If and when the two sides of the architectural coin we flip with solutions!

.Doc

Excepts from my upcoming book

Show don’t tell, make migrations easier!

It’s an interesting concept that I’ve covered in my blog a number of times https://docandersen.wordpress.com. How do you provide another organization with a roadmap to where they want to go?

1. What does a transitional service mean to the organization you are working with or for?

2. What does a successful project mean in the organization?

3. What does a failed project mean in the organization?

4. How do they/you measure failure and success?

I’ve been a consultant and IT person for over 20 years now. During that time I’ve come to realize that the most painful thing for a company to do is to migrate anything to anything. That is the rationale behind the tool that was selected for this process (ReGen) and the various processes offered within Microsoft SharePoint Portal Server (MOSS). Making migrations easier is a goal of transitional services, helping organizations become more agile as they progress through the process. The reality of migrations is not that they are difficult, it is that the migration being undertaken is probably more complex than the organization realized.

 

.doc

Change, the last friendly house

Over the past year i have written about creating lighthouses near issues or problems in the solution you are deploying to warn people of what is coming.

My next great idea (if of course this really isn’t my first, and perhaps not even a great idea) is the concept from the Hobbit by JRR Tolkien, the concept of the last friendly house.

Elrond of course was the owner of that last friendly house before the wilderness that represented the wilds of Middle Earth. We should do the same thing for software solutions when you are heading into uncharted or new territory.

The last friendly drop of code 🙂

.Doc

Additional thoughts on the national healthcare debate

The cost of a universal healthcare system based on the system we have in the US today would be incredible. But, there are a number of things we can do that would alleviate some of the costs of the system and bring things closer to a universal system at a significantly reduced price.

  • Reduce the maximum amount for medical damage or malpractice suits.
  • Provide universal malpractice insurance for doctors and other medical providers
  • Determine which services are most critical and provide those for free to everyone

Any system based on providing everyone the minimum has two inherent issues. The first is that you move the minimum bar so far down the scale that it becomes useless. Or, the system ends up costing so much money that you end up with a 35-50% tax rate for everyone.

If we can leverage the first two bullets and then automate as many services as are possible using technology as the equalizer we may be able to pull this off.

The problem is, no one has a 3 years plan. everything is geared to right now – which means we are going to be a risk again, in less than 3 years.

.doc