Your company probably has a business plan. Your company probably relies on some level of IT functionality and services to perform its business operations. It makes sense to have an architectual roadmap that paints a picture of how the IT services will work together in the short and long term to help fulfill the business plan. Waiting for the business to dictate what applications and functionality they need just won't work. Business moves fast and the IT system changes are the last thing on the mind of the business. If you wait for the business to tell you what you need it will already be way too late to implement any reliable, extensible system. Instead you will end up with a bunch of band aids that will build up like a house of cards over time.
I'm not suggesting that you need to have a crystal ball but there are certain things that you can do to be prepared for these changing business requirements. Having a roadmap is one of these items. Having a constant dialog with decisions makers in the business is another. This doesn't have to be a formal meeting it could just be going to lunch with someone from the business once in a while. As an IT professional its your responsibility to be a consultant to the business. That means keeping abreast of the new features of current technologies that are implemented and also new systems and technologies that are not yet implemented but would provide value to the business process. If individuals from the business are coming to you and telling you what applications to buy and how something should be implemented then your IT department needs to get on the stick and should be anticipating these requests and driving the technology decisions.
The roadmap starts by meeting with the business to understand where the business is going. What's the vision from the business on the types of products and services that will be offered and in today's world what is the vision of how these can be augmented or promoted through technology. Information and interaction with your customers via the Internet and its different technologies is a must in addition to the internal systems that will support the business process. Also, what are the types of information exchange does the business want to do with vendors, partners, and industry consortiums?
The items that should be in the architectural roadmap are security plan, server strategy, application strategy, Internet strategy, infrastructure, etc.. All these different plans should include an assessment of what is currently in place, what the long term strategy is for each area, and then a short term list based on business priorities, security priorities, and then redundancy issues (for example a legacy process that has no redundancy or backup). Having the roadmap allows for stategic decisions as systems are upgraded or changed. When a request comes through to make a change or add an application, these actions should be carried out in accordance to the roadmap.
The architectural roadmap should also provide guidelines for systems that will be introduced to the mix. For example if you choose Active Directory as your system for authentication then it should be a requirement that any applications that are looked at for purchase must support Active Directory authentication. Another guideline should be a requirement that any system that's implemented must have an open interface to allow integration with other systems. You may even want to clarify even further that the system must provide a services interface so that it is not technology specific.
Another thing to consider is what type of platform you would prefer your applications to run on. In today's world if you are a company of any size then you will have applications that are based on both .Net and Java/J2EE. Saying that you will only support one or the other may restrict you from providing the right solution. As long as the applications provide a non-technology specific interface (web services) then the platform shouldn't matter. The question comes in of which technology you want to use for your custom developement. Unless you are a large shop you will have to pick one or the other. The other alternative is to try and find developer talent which is proficient in both which is not impossible but these will be senior people on the high end of the pay scale. Which isn't a bad thing but just don't think your going to get junior developer talent that is effective in both environments.
There are many more details that I will emphasize in future blogs. The important thing is to not just let IT happen. Going with the flow and waiting for the business to dictate what system they want so that you can blame them later if it doesn't work is just not the way to go. Having an architectural roadmap that is the result of understanding business near and long term needs and then working the plan as changes are made is the way to provide the best value from your IT services. As the plan matures the IT organization will be able to react faster to changes in business.
