Together with a colleague of mine we wrote an article for a Belgian/Dutch IT-magazine informatie (www.informatie.nl). In this article we point out how we execute architecture within our company and that we give special attention and focus on the architecture process.
Although referential architectures are key in developing a view on the future, these referentials can be a stumbling block for specific (urgent) business needs. In that case a partial deviation or interruption on the way to the future vision can be allowed at strategic architecture board. This board consist off business and IT management so that they can decide from their responsibility and general consensus.
In short the future vision embedded in referential architectures is important, but the architecture process is also (or even more?) important. This is written down in the article (in Dutch only).
If you agree or disagree with this statement or have any other comments, please let me know!
Sunday, April 13, 2008
Tuesday, February 26, 2008
Changing borders Business will become IT
In many companies the implementation of Business Rules Engines and product engines are executed or planned to be in the near future. Often the biggest reason for implementing these type of solutions is to parameterise decisions or product specifications that formerly were hard coded in software. When implementing the business is back in the driver seat again, and we can quickly implement changes without the IT-department.
All this is true I think, but I see this as a next maturity stage in software development and maintenance. When the business sees the type op parameterisation required, they will see that this is very strict and formalized. In a way it is another way of programming the system by function designers.
It is my opinion that after a while the “real” business will decide that this type of work should be done in the IT-department and that all the personnel trained in configuring rule engines and product engines will be called IT (again). So the borders of the business will be moved toward the business core competence.
Please react or give your comments.
All this is true I think, but I see this as a next maturity stage in software development and maintenance. When the business sees the type op parameterisation required, they will see that this is very strict and formalized. In a way it is another way of programming the system by function designers.
It is my opinion that after a while the “real” business will decide that this type of work should be done in the IT-department and that all the personnel trained in configuring rule engines and product engines will be called IT (again). So the borders of the business will be moved toward the business core competence.
Please react or give your comments.
Subscribe to:
Posts (Atom)