Category Archives: Patterns and Good Practices

New Knowledge Page focussing on REST, SOA, APIs and Microservices Available

Recently I’m involved in various activities around APIs and Microservices. Unfortunately, I discovered that especially in relation to Microservices, it’s the same setting as with Digital Transformation. Usually the topics aren’t put into perspective and therefore ignorance leads to the ‘Great! It’s new!‘ effect. However, a lot of the ideas, concepts, pattern and principles already exist, are well-documented and thus should be reused.

Therefore, I’m currently working on a new page called Reference Models and Architectural Styles in the Knowlege & Links section that aims at listing some valuable books, articles and standards in the categories REST, SOA, APIs and Microservices. You could think of those resources as a kind of foundation for the topics although they don’t build on each other in every case. I’m going to update the page, as soon as I identify further interesting sources.

Do you know further resources which you consider as fundamental in relation to the topics REST, SOA, API and Microservices?

Sound off in the comments!

The Myth of Digital Transformation

At the moment Digital Transformation (sometimes also called Digitalization or just Digital) is a prevalent term used on the Internet, in research and various industries. The behemoths of the consulting business have shaped offerings around Digital Transformation (e.g. Accenture, PWC, CapGemini, McKinsey) and established research organizations have embraced the theme (e.g. MIT Center for Digital Business, Digital Business Initiative of Stanford Graduate School of Business). Of course, the big IT research and advisory companies picked up the topic too (e.g. Gartner, Forrester).

In essence, all the fundamental ideas, concepts and approaches of Digital Transformation can be summarized as follows:

  • The leverage of technologies like cloud computing, data analytics, mobile apps, APIs, social media platforms, machine learning, Internet of things, smart & connected devices, etc.
  • The leverage of concepts and approaches like DevOps, agile software development, pace layering, bimodal IT, etc.
  • The usage of those technologies, concepts and approaches to design and implement new business models

Although the term is widespread used, I’m amazed that it isn’t put into some kind of perspective and therefore often conveyed and hailed as a new concept.

When I was reading various books, articles, posts on the topic, the idea struck me that Digital Transformation is essentially a just specific pattern of business and IT alignment and therefore isn’t a new concept. Hence, I revisited the fundamentals of strategic business and IT alignment to verify my idea.

Eventually, I contend that the concept of Digital Transformation isn’t fundamentally new. It is a just specific perspective of the problem how to align strategic choices of the business and IT domain effectively. This can be proved by mapping the ideas, concepts and approaches of digital transformation to the Strategic Alignment Model of J.C. Henderson and N. Venkatraman – a model that is nearly 24 years old and still valid.

Introduction of the Strategic Alignment Model

J. C. Henderson and N. Venkatraman developed the Strategic Alignment Model to support the strategic management of evolving IT in 1993. It consists of four fundamental parts: Business Strategy, IT Strategy, Organizational Infrastructure and Processes, and IT Infrastructure and Processes. The parts are discrete and contain categories of strategic choices.

strategicalignmentmodel

The Business Strategy and IT Strategy make up the external domain: An outward-oriented view on how the organization differentiates from its competitors. The Organizational Infrastructure and Processes, and IS Infrastructure and Processes represent the internal domain: An internal view on the set strategic choices that can be leveraged within the organization.

In addition, the Business Strategy and Organizational Infrastructure and Processes are focusing on the business and thus represent the business domain. The IT Strategy and IT Infrastructure and Processes zoom in on IT aspects and therefore represent the IT domain.

Although the domains and parts of the model are self-contained, they interrelate with each other. In fact, the effective management of business and IT requires to balance all strategic choices within each part. In particular, the alignment of the external and internal domains is called strategic fit and the alignment of the business and IT domains is named functional integration.

Each part of the model contains three categories of strategic choices. Although some of the names seem to be odd today, the scope and contents of each category are still consistent.

The Business Strategy groups strategic choices with respect to the scope and distinctive competencies of the business, and the Business Governance. The former deals with all aspects of a business model including for example customer segments, value propositions, channels, customer relationships, etc. (cp. with the Business Model Canvas from A. Osterwalder and  Y. Pigneur). The latter category called Business Governance is quite confusing: It deals with make-or-buy choices as part of the business strategy – an aspect that could also be included in a business model today.

The IT Strategy is similar to the Business Strategy part but it has a distinct focus on the IT domain. The Technology Scope deals with the deliberately-defined compilation of information technologies which support current and future business strategies. The Systemic Competencies are the IT-related capabilities that support the business strategy by contributing a distinctive, competitive advantage to the organization.

As part of the internal and business domain, the Organizational Infrastructure and Processes define how the business should work and what business-related skills are required within the organization. This part consists of administrative functions, (business) processes and (business) skills. Today the term business architecture could be a more appropriate name for this part.

The last part is the internal and IT-related domain called IS Infrastructure and Processes. It consists of (IT) Architectures, (IT) Processes and (IT) Skills, and essentially describes how the IT should work, what applications and infrastructure components are deployed and which skills are required in the internal IT-related domain.

In order to effectively manage business and IT coherently, an organization has to balance all strategic choices within each category, part and domain. As there are a lot of combinations across all strategic choices possible, J. C. Henderson and N. Venkatraman postulate to focus on the cross-domain relationships. Particularly, they suggest four common patterns which describe the fundamental sequence in which the four parts should be aligned:

  1. Strategic Execution: Business Strategy  Organizational Infrastructure and Processes  IS Infrastructure and Processes
  2. Technology Transformation: Business Strategy IT Strategy IS Infrastructure and Processes
  3. Competitive Potential: IT Strategy  Business Strategy  Organizational Infrastructure and Processes
  4. Service Level: IT Strategy IS Infrastructure and Processes  Organizational Infrastructure and Processes

Of course, those patterns just represent general guidelines of how to align all strategic choices according to the defined sequence. Actually, a lot of other dependencies and trade-offs between the strategic choices have to be considered.

Mapping of the Digital Transformation Concepts to the Strategic Alignment Model

The essential ideas, concepts and approaches of Digital Transformation can be mapped to the Strategic Alignment Model as shown in the following figure.

strategicalignmentmodelmapping

If an organization wants to leverage technologies like cloud computing, data analytics, mobile apps, APIs, etc., the Technology Scope of the IT Strategy is the main category to start with. Essentially, the technologies which are available in the market have to be identified, analyzed and evaluated. Any technology that supports the current business strategy or could potentially shape the design of a new business strategy (or business model) should be included within scope of technologies.

The idea to leverage concepts and approaches like DevOps, agile software development, pace layering, bimodal IT, etc. can be assigned to the category Systemic Competencies of the IT Strategy. Along the lines of the Technology Scope, any IT-related capability that supports the current business strategy or could potentially enable a new business strategy should be a strategic competency of the organization.

Of course the selection of strategic technologies and capabilities is only a starting point. If an organization wants to embrace and master a technology, a change activity is required to learn the new technology, build up the skills and make the technology generally available within the organization. Analogous IT-related capabilities have to be build up or enhanced by implementing a change process within the organization. Think of both categories as the initial trigger on the strategic level to introduce a specific technology or capability to the organization.

The usage of technologies and capabilities to design and implement new business models is clearly related to the part Business Strategy. The Business Scope, Distinct Competencies and Business Governance (that is to say the business model) should consider and work with all technologies and capabilities defined within the IT Strategy. Of course, as with the IT Strategy, this is just the starting point and a business model has to be implemented eventually.

The latter aspect of Digital Transformation also indicates the primary pattern of aligning all the strategic choices: Competitive potential. The IT Strategy including the Technology Scope and Systemic Competencies is the enabler for the business: IT could enhance or facilitate business models and thus the Business Strategy.

strategicalignmentmodelcompetitivepotential

Certainly there are a lot of other dependencies in relation to the IS Infrastructure and Processes that is to say the internal, IT-related part but the pattern prescribes the fundamental sequence in which the parts should be aligned.

Conclusion

The concept of Digital Transformation isn’t fundamentally new. It is a specific perspective of strategic business and IT alignment. The ideas, concepts and approaches of Digital Transformation smoothly fit into the components of the Strategic Alignment Model – a model which is nearly 24 years old. Therefore, within any conversation you should pay attention to way Digital Transformation is explained and positioned. In either case challenge your interlocutor (or the book, article or post you’re reading) by simply asking: What is essentially new to the concept of Digital Transformation?

In addition, there are further implications that should be considered. Firstly, as Digital Transformation is fundamentally just a specific perspective of strategic business and IT alignment, all the existing concepts, frameworks and tools could (actually should) be considered and reused. Thus, if you have to deal with Digital Transformation, you should have a look at the fund of knowledge that is already available. The following figure illustrates some building blocks that could be leveraged to support the effective alignment of business and IT.

strategicalignmenttoolbox

Please note that further sources in relation to the shown concepts, frameworks and tools are available on the following knowledge base pages: Business Strategy and Business ModelsIT Strategy and Governance, Enterprise Architecture Management, Pattern and Good Practices.

Secondly, if there is anything new to the concept of Digital Transformation, it is related to new combinations of technologies, capabilities and business models that enable an organization to accomplish a goal that wasn’t possible before. A new and effective combination can be considered as a pattern of specific, strategic choices and their successful implementation. Therefore, if you have to deal with Digital Transformation look after those patterns and try to figure out whether you could reuse a specific pattern. A good example is the book by G. Westerman, D. Bonnet and A. McAfee: Leading Digital – Turning Technology into Business Transformation. Although they aren’t describing those patterns explicitly, the book contains some interesting case studies about organizations and companies successfully implementing those combinations. The authors were also involved in several empirical studies verifying the effectiveness of implementing ‘digital pattern’. Nevertheless, the concept and approach for analyzing and implementing those patterns aren’t new – it is essentially business and IT alignment.

Thirdly, the methods for delivering the pattern are available but what’s currently unavailable is an approach for documenting the ‘digital pattern’ in a structured and detailed way. I’m thinking of a structure which has to be described up to the level of an enterprise architecture model (see for example the ArchiMate standard) and that elaborates on the objectives and trade-offs of each pattern.

Fourthly, it is amazing to see that the Strategic Alignment Model – which was developed by J. C. Henderson and N. Venkatraman nearly 24 years ago – is still valid and thus can be used today. Some names sound odd but the semantics and logic are still substantive.

What do you think about Digital Transformation? Do you know common ‘digital pattern’? Did you already find your pattern that supports your organization effectively?

Sound off in the comments!

References

Henderson, J.C.; Venkatraman, N. : Strategic alignment – Leveraging information technology for transforming organizations. In: IBM Systems Journal, Vol. 32, No. 1, 1993.

Osterwalder, A.; Pigneur, Y.: Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. John Wiley & Sons, 2010.

Westerman, G.; Bonnet, D. ; McAfee, A.: Leading Digital – Turning Technology into Business Transformation. Harvard Business Review Press, 2014.

No Politics, Just Great Architecture

A few days ago a friend of mine changed the short description of his business on his Linkedin page to the slogan: ‘No politics, just delivery.’. What a brilliant slogan! He’s working in the IT project business for many years and I assume that he’s tired of all these projects that are heavily influenced by politics. Of course each nontrivial IT project has to deal with miscellaneous stakeholders and their conflicting objectives/requirements including politics but I think he’s referring to those ones where politics dominates and sometimes leads to strange decisions and project conditions.

Transferring his idea to my primary business of (enterprise) architecture management I adopted it spontaneously to ‘No politics, just great architecture.’ because sometimes there is architectural work that is heavily influenced by politics too. When I spend a few more thoughts on it I was struggling with the adjective great. Of course there is no great or even bad architecture. Remembering the very basics of evaluating architectures an architecture always has to be considered in its context that is framed by the specified requirements (including objectives, principles, constrains) that it has to fulfill (see [ClKK2002, Mali2008]). So it’s much better to characterize it as a capable architecture, i.e. an architecture that fulfills all the requirements that are imposed to it, but ‘No politics, just capable architecture.’ doesn’t sound so smashing… 😉

Anyway there is still the question how to deal with such situations which are heavily influenced by politics. When looking at the enterprise architecture discipline in particular what should an enterprise architect do if he realizes that he is doing architectural work in a politics dominated environment? Furthermore from my point of view it is interesting if there are any best practices or strategies how to cope with such challenges. When looking at TOGAF for example (see [TOGAF2011]) there’s no special chapter or topic explicitly dealing with this question but of course there are a lot of basic methods, guidelines and techniques described in this framework (e.g. architecture requirements management, stakeholder management) that provide the foundation for coping with such situations.

When thinking of the most important pillars of this foundation I came up with the following ones:

1. The role of the enterprise architect should be executed in an objective manner

The enterprise architect role is responsible for providing a capable (alias ‘great’) architecture that fulfills the requirements imposed to that architecture as good as possible. When investigating and evaluating the architectural options the architect himself should be objective, i.e. he should adhere to the facts and should not rely on personal flavor. You might say: ‘Yes, of course!’. Sounds like simple logic but it isn’t… According to Bass, Clemens and Kazman there are four major factors that influence the development of an architecture: Stakeholders, the developing organization, the technical environment and the architect’s experience (cp. [BaCK2003, p. 9-12]).

Source: On the basis of [BaCK2003, p.11]

The latter characterizes the fact that within the development of an architecture the architect gains additional knowledge and extents his experience (cp. [BaCK2003, p. 11]). A successful implemented architecture will inspire an architect to design a similar architecture for another project. An architecture that fails to deliver the expected requirements (including objectives, principles and constraints) is unlikely to be chosen second time. If an architect has little experience with respect to an architecture, architectural building block and/or architectural pattern it is less likely that he will take it into the range of design options.

Therefore an architect should be beware of the fact that his experience influences the architectural design process. In addition he should be open and curious in relation to previously unknown or unapplied design options. These might be the better ones although they were not used by the architect yet.

2. Document the design decisions taken and their rationale

Going back the very basics of documenting architectures the design decisions taken and their rationales should be a mandatory part of the architecture documentation. For example Clements, Bachman, Bass et al. describe this idea in their ‘Seven Rules for Sound Documentation’ (Rule 5: Record Rationale, see [CBBG2003, p. 24-29]). Here it is important to notice that all evaluated options should be documented to support the transparency of the decision process – not only those leading to the final design. Therefore each template for architecture documentation should contain a dedicated chapter and/or structure supporting this part of the documentation.

In case the architect works on the enterprise architecture level a motivational model as part of an overall EA metamodel supports the explicit modeling of the objectives, principles, requirements and constraints and their linkage to the architectural decisions and elements respectively. Take for example Open Groups’ ArchiMate standard which contains such an motivational model in its latest version 2.0 (see [TOGAF2012] and this related post).

3. Use qualitative metrics to the most possible extend

The paramount architectural evaluation is based on qualitative metrics solely but in rare cases the architect has all underlying data and evaluation models and therefore is able to calculate all required metrics. Nevertheless the architect should strive for using qualitative metric by identifying available basic data, useful evaluation models and trying to combine architectural decisions with relevant metrics. In case there are at least some metrics available pure political decisions could be argumented against easily.

REFERENCES

  • [BaCK2003] Bass, Len; Clements, Paul; Kazman, Rick: Software Architecture in Practice. 2nd Edition, Addison-Wesley, Boston et al. 2003.
  • [CBBG2003] Clements, Paul; Bachmann, Felix; Bass, Len; Garlan, David; Ivers, James; Little, Reed; Nord, Robert; Stafford, Judith: Documenting Software Architectures – Views and Beyond. Addision-Wesley, Boston et al. 2003.
  • [ClKK2002] Clements, Paul; Kazman, Rick; Klein, Mark: Evaluating Software Architectures – Methods and Case Studies. Addison-Wesley, Boston et al. 2002.
  • [Mali2008] Malich, Stefan: Qualität von Softwaresystemen – Ein pattern-basiertes Wissensmodell zur Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen. Gabler, Wiesbaden 2008.
  • [TOGAF2011] The Open Group: The Open Group Architectural Framework (TOGAF).  Version 9.1, 2011.
  • [TOGAF2012] The Open Group: ArchiMate 2.0 Specification. Technical Standard, February 2012.

TOGAF 9.1 released

The Open Group released Version 9.1 of TOGAF. According to this post of Andrew Josey and Garry Doherty version 9.1 is no major release but a maintenance update which includes over 450 changes to the standard. It is assumed to be upward compatible with version 9.0.

Andrew Josey’s and Garry Doherty’s post summarizes some of the most important updates. For a detailed view on all changes you might dig into the Technical Corrigendum No. 1 describing a detailed list of all changes to the standard document.

I updated my knowledge base to refer to the new version of the framework (Knowledge Base – Enterprise Architecture Management – Frameworks and Standards).

Welcome to the Architectural Change Management Blog!

My name is Dr. Stefan Malich and I devote myself to the disciplines of enterprise and software architecture. I started my career as a freelance IT consultant and software developer. In 2001 I joined the global management consulting company Accenture. Within the consulting business I developed many architectures and led several architecture teams mainly in whole sale, the financial services and energy industry. In a sabbatical leave I was engaged
at the Institute for Computer Science and Business Information Systems and worked on a personal PhD research project which dealt with pattern-based architectural knowledge. After finishing my doctoral thesis I’ve focused on enterprise architectures and worked on several enterprise architecture projects within the financial services and energy industry. I led projects to build up or enhance enterprise architecture capabilities and gained explicit knowledge of the various aspects of an enterprise architecture capability (processes, models, governance, roles and functions, tools, maturity models etc.).

Lately I’m looking into the change management aspects of the enterprise architecture management discipline and that’s what this blog is all about.
My observations led to the thought that – especially when building or enhancing an enterprise architecture capability – enterprise architecture management is even more than e.g. staffing an enterprise architecture team, defining an EA meta model and deploying an EA tool. It is about developing
an EA team with the right skills, building up the relevant architectural knowledge and positioning the results of the EA team for use within the company. In many companies this situation leads to a fundamental change in the way it is concerned with enterprise and software architectures. Existing capabilities, goals, skill sets, processes, governance and organizational structures etc. are questioned and major change transformations are needed to build up or enhance the enterprise architecture capability.

This blog will adress the challenges of such an architectural change transformation. Currently I think of the following questions that guide my work:

  • To develop an EA team with the right skills and relevant architectural knowledge you need know the state of art of the enterprise and software architecture disciplines. You do not want reinvent the wheel, right? This blog already contains a pretty large list with links and knowledge sources covering enterprise architecture, software architecture and other topics. Of course this list is not exhaustive but to my mind all entries are valuable.
  • How do you effectively build up architectural knowledge? With regard to the architecture itself patterns and ‘best practices’ are a proven approaches. Take a look at the Patterns and Good Practices page. But how  do you build up knowledge  concerning the enterprise architecture management capability (e.g. processes, models, governance, roles and functions, tools)?
  • What is the state of the art of the change management discipline? What can we learn and reuse from this discipline?

If you interested in this challenges revist this blog, subscribe to it or contact me directly.