Standards increase the homogeneity of an IT landscape by limiting the number of allowed in-use technologies. If implemented correctly, standards lead to cost savings and improved productivity with regards to IT solutions.
IT Standards Foundations
IT standards steer the development of an enterprise architecture by limiting the number of allowed technologies and by defining minimum thresholds for the delivery of IT services [Fuh11d]. A visual example of how IT Standards restrict the design space in the context of the managed evolution approach is given in Figure 1. The goal of standardization is to decrease complexity in an IT landscape and thereby enable better manageability and control [SGM15].
Figure 1: Influence of IT standards on the design space of the enterprise architecture in the context of the managed evolution approach. [Based on: K. Fuhrer. “Architecturmanagement: Migrationsschritte zur Servicelandschaft, SOA-Transformation.” In: Business Technology (bt) Magazin 1 (2013).]
Standards can be categorized according to three different classes. The first class are legal and regulatory obligations, comprising standards mandated by law. The second class are industry standards, which are established by industry bodies and adopted by organizations on a voluntary basis. The advantage of adopting this kind of standards is that they could offer potential for inter-operation across enterprises of the same industry. The third and last class of standards are the organizational standards, which are set within an organization [11b]. In practice this usually means, a book of standards is developed which lists products and technologies allowed to be used in future projects [SGM15] but it could also comprise the definition of reference architectures, architecture patterns or EAM frameworks which are to be applied in the transformation of certain parts of the enterprise architecture [Nie08; Fuh11d].
Further, IT standards operationalize the IT strategy and the IT principles [Fuh11d; Fuh13b]. This link can be illustrated using an example taken from [Buc10a]. The basic assumption is that an organization has an EA principle in place, which obliges the IT department to concentrate development competences [Buc10a]. This EA principle can be operationalized by establishing an IT standard stating that only a restricted set of programming languages can be used in future projects [Buc10a].
The creation and establishment of IT standards is a difficult and costly process [SGM15]. Standards can be created in a bottom-up or a top-down manner [Nie08]. If the bottom-up approach is used, the standards are defined based on best practices, lessons learned and other experiences made during projects [Nie08]. Advantages of this approach are that standards are concrete and pragmatic [Nie08]. Nevertheless, it can also lead to unnecessarily proprietary solutions [BBL12]. On the other hand, using the top-down approach, IT standards can be derived directly from the enterprises strategy [Nie08]. This way, the bigger picture with regards to the goals of the enterprise are maintained, but it can also easily drift into a blind enforcement of standards (ivory tower syndrome) [BBL12]. In conclusion, a good strategy is to combine both approaches.
To measure the progress of standardization efforts, KPIs can be used [SGM15].
The enforcement of standards facilitates decision making by limiting the amount of solution options [BBL12; Fuh13b; Fuh11d]. The best possible case would be that standards enable project teams to just assemble a significant portion of their solution [BBL12]. This leads to a decrease in the amount of possible integration scenarios as well as to a decrease of integration costs and risks [SGM15].
Choosing good standards is difficult. On the one hand, they have to foster complexity reduction by limiting possible technology solutions to be used and thereby enable manageability and control of the application landscape [BBL12]. On the other hand, they should not constrain the need for diversity and flexibility of solutions demanded by the business too much [BBL12; Fuh11d]. Excessive standardization efforts can also lead to a dependency on certain technologies or vendors [SGM15].
Sources:
|
[Fuh13a] |
K. Fuhrer. “Architecturmanagement: Migrationsschritte zur Servicelandschaft, SOA-Transformation.” In: Business Technology (bt) Magazin 1 (2013). |
|
[Fuh11d] |
K. Fuhrer. “Teil 4: Standardblickwinkel und Praxissichten Infrastruktur und Technologie, Resümee und Ausblick.” In: Enterprise Architecture Deliverables: Welche Ergebnisse liefert Enterprise Architecture? OPITZ CONSULTING GmbH. 2011. |
|
[SGM15] |
A. W. Schneider, A. Gschwendtner, and F. Matthes. IT Standardization Survey 2015. Tech. rep. Chair for Software Engineering of Business Information Systems. Technische Universität München., 2015. |
|
[Nie08] |
K. Niemann. “Enterprise Architecture Management and its Role in IT Governance and IT Investment Planning.” In: Advances in Government Enterprise Architecture. IGI Global, 2008, pp. 208–228. |
|
[BBL12] |
S. Bente, U. Bombosch, and S. Langade. Collaborative Enterprise Architecture: Enriching EA with Lean, Agile, and Enterprise 2.0 Practices. Elsevier, Inc., 2012. |
|
[Fuh13b] |
K. Fuhrer. “Business-SOA und technische Integration: Migrationsschritte zur Servicelandschaft.” In: Business Technology (bt) Magazin 2 (2013). |
| [11b] | The Open Group. 2011. TOGAF® Version 9.1, an Open Group Standard. |
|
[Buc10a] |
S. Buckl. “A Conceptual Framework for Enterprise Architecture Design.” In: Trends in Enterprise Architecture Research - 5th International Workshop, TEAR 2010. Ed. by |