IT strategy and IT Architecture Frameworks are too much based on Business strategy and Business Architecture.

Today both IT strategy and IT Architecture Frameworks are too much based on Business strategy and Business Architecture. One makes this as prerequisite architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.). But is this smart when one expect that the business strategy will last much longer than the IT strategy?

Christian Wig has some interesting remarks:

“When people tell me that the IT strategy should be 'driven' by the business strategy, I normally tell them that their underlying paradigm is fundamentally wrong. Or I ask them to provide me with a business strategy having a 10 years’ time perspective, which - of course - never exists (and never should exist). Or, I tell them that if we meet again 10 years from now, in the same boardroom of the same company, that they will be highly frustrated by how the IT architecture of the 2020s actually prohibits business development - driven by the 'business-driven' IT decisions we made together back in 2010.

This paradox is a quite critical one facing most businesses today: The technology platform that supports their business areas, products and processes have a much longer life-span than the business strategies which the technology is supposed to support. And at the same time, no technological platform will be 'prepared' for handling anything that wasn't explicitly foreseen and planned for. So the ability to look around the corner, and actually plan for the unplanned, is what I really focus on.”

Is it possible to manage the enterprise architecture without implementing architecture principles?

From the Open Group (http://www.opengroup.org/architecture/togaf8-doc/arch/) we find the following definition of different principles. Depending on the organization, principles may be established at any or all of three levels:

Enterprise principles provide a basis for decision-making throughout an enterprise, and inform how the organization sets about fulfilling its mission. Such enterprise-level principles are commonly found in governmental and not-for-profit organizations, but are encountered in commercial organizations also, as a means of harmonizing decision-making across a distributed organization. In particular, they are a key element in a successful architecture governance strategy (see Architecture Governance).

Information Technology (IT) principles provide guidance on the use and deployment of all IT resources and assets across the enterprise. They are developed in order to make the information environment as productive and cost-effective as possible.

Architecture principles are a subset of IT principles that relate to architecture work. They reflect a level of consensus across the enterprise, and embody the spirit and thinking of the enterprise architecture. Architecture principles can be further divided into:

o Principles that govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture

o Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designing and developing information systems

These sets of principles form a hierarchy, in that IT principles will be informed by, and elaborate on, the principles at the enterprise level; and architecture principles will likewise be informed by the principles at the two higher levels.

Is Maven still the best build tool?

We use Maven as build tool; it handles and centralizes all build, dependencies, reporting and documentation. Since we do not rely on restricted software and do not deploy our applications into a javaEE environment we can package our software with all dependencies included. Maven is configured to build a zip archive of our servers with all configuration included ready for installation on any server using simple Unix and Linux commands. Maven does not lay any restrictions on which IDE the developers use.