Anyone can take information from this weblog as long as (s)he refers to it origin properly.
Taken from an earlier weblog: An IT-Architecture is the view of IT-professionals on the technical IT-infrastructure, written down in models, languages etc. Here we are talking about the world of the IT-vendors who are creating hardware, networking, systemsoftware etc.: systemhouses. The IT-architecture is a shared view of the technical IT-infrastructure, their reality.
When an organisation wants to "buy" an IT-solution, the procurement must include a specification of what the organisation wants in terms of functionality. It is highly recommended to include conditions, demands, wishes etc. of the organisation around the procurement and around these functional requirements. This way the IT-vendor knows what is possible and what is not possible in this organisation. This should be as complete as possible.
Including IT related specifications, conditions, demands, wishes etc. may affect the proposals of IT-vendors to a large extend. In general there are two cases:
- The requested IT-solution will be part of the IT-infrastructure that is under the direct control of the organisation.
- The requested IT-solution will not be a part of the IT-infrastructure that is under the direct control of the organisation. The IT-infrastructure may be managed by another party, the solution may be part of an outsourced (onshore, offshore etc.) IT-infrastructure etc.
Of course it is important to let an IT-vendor know about related parts of the current and future IT-infrastructure.
It is dangerous to specify and prescribe new services, IT-structures and changes in the related IT in the specification. To tell an IT-vendor, by including it in the specification, in what way the IT-solution is to be structured and/or the way the IT must be changed limits the creativity and the possibilities in which an IT-solution can be formed and created. In the case the IT-infrastructure is controlled by the organisation itself it is logical to have a larger number of requirements on the IT of the new solution than in the case the organisation does not manage the IT-infrastructure. After all it is the controlling that will have to manage the result.
The reason for not including IT requirements and specifications is simple. If an IT-vendor is forced to create an IT-solution that is specified-in-full it is nearly always impossible to use existing knowledge and available parts. Therefore former results can only be used in concept, not in available code and experience. This can, and usually will, affect the quality of the resulting IT-solution, because again and again something new is created. If we can use existing structures and code the quality of the result will be better from the start, and the price will usually be (much) lower.
These are the reasons that lead to this position: "organisations that include an IT Architecture in the specification of the procurement of an IT-solution usually do not get the best and cheapest solution possible".
Click here for received comments (none received yet).