Decision Making | The Federal Architect

It’s harder getting out than getting in - improve your RFPs

Posted by Shahid N. Shah in Decision Making on July 20th, 2008

We’ve all seen it: we spend weeks or months in the “sales and demo cycle” for our applications. If we’re lucky we consider all workflows, if we’re even luckier we test drive the UI and make sure training goes smoothly, if we’re smart we also try to ensure that deployment will be easy. However, what we all seem to forget is to figure out how to get out of an application or system after it’s been installed for a while.

Why is getting out important? Because every application becomes “legacy” sooner or later. Every system will be replaced or augmented at some point in time. The cost of acquisition (”barrier to entry”) is well understood now as something we need to calculate. How about the barrier to exit or switching cost? Do we calculate that when we decide what systems to purchase? Why not?

If you can’t answer the “how, in 24 months, will I be able to move on to the next-better technology or system?” question then you’ve not completed your due diligence in the sales cycle.

When preparing an RFI or RFP, ask vendors specific questions about how easy it is to get out of their technology (rather than just how easy to it is to deploy and interoperate). Put in specific test cases and have your folks consider this fact when they are looking at all new purchases. Here are some specific factors to consider:

Do you own your data or does the vendor? Make sure it’s explicit in your RFP.
Is the database structure and all data easily accessible to you without involving the vendor? If only your vendor can see the data, you’re locked in so be very wary. In the RFP make sure it’s clear that you want this documented and provided to you.
Are the data formats that the system uses to communicate with other vendors open? If not, you don’t own your data. Make sure the RFP explicitly states you want the data formats.
How much of the technology stack is based on industry standards? The more proprietary the tech, the more you’re locked in.
Are all the programming APIs open, documented, and available without paying royalties or license costs? If not, when you try to get out you’ll pay dearly.

If you have other considerations, share them here.

Share/Save

No Comments

Traits of good architects and technical leaders

Posted by Shahid N. Shah in Decision Making, Leadership on July 20th, 2008

Many of my younger colleagues often ask about what some of the most important leadership aspects are for technical managers like team leads or architects. There are no hard and fast rules but here are some things I’ve learned over the years:

Make Decisions. This is one of the most important aspects of leadership — just making a decision and not analyzing for weeks or months. No amount of evidence or information will ever “be enough” and at some point you’ll need to make a decision. Your team can see if you are timid or if you take risks. Leadership is about decision making and if your decision making skills or risk taking ability are limited, don’t bother trying to lead. I’ve seen many architects and so-called “team leads” that try to get their bosses to make their decisions for them so they don’t get in trouble for making “the wrong ones”. Big mistake.
Lead by Example. Leadership is about direction and if you want to lead, you’ll need to make sure you take charge and establish that you know where you want to go. But, be prepared to demonstrate that you do what you ask your team to do. If you ask everyone else to do something but don’t do it yourself, your team will lose respect.
Be transparent. You work with bright people and although they may not be your equals in experience or knowledge, they will know when you are making decisions based on whim or reason. If you can’t explain your decisions in a way that your team can comprehend then you’re not a good leader.
Mentor. Good leaders create the next group of leaders, not just bark orders. If you’re not regularly mentoring and training, you’re not doing your job. And, if you mentor well you can let your team make many of the decisions without you and you’ll be able to trust that their decisions will be as good as yours.
Be inclusive. You’re the leader and can make all the decisions and everyone knows that. But, if you’re not including input from everyone you’re losing valuable data and a chance to build a cohesive team.