Category Archives: Software Architecture

Architectural Reference Models related to Smart, Connected Devices

Lately I figured out that I haven’t covered resources on the topic of Smart, Connected Devices (aka Internet of Things (IoT)) in the knowledge base. As the topic spreads across multiple architectural domains (business, application and infrastructure), I’ve updated several knowledge base pages. Please note that the current resources are just a start.

Views on the Business Model & Business Architecture

The high-level business view on the topic of Smart, Connected Devices is excellently described in two Harvard Business Review articles by M. E. Porter and J. E. Heppelmann (see the section Smart, Connected Devices (aka Internet of Things) on the knowledge page Business Strategy and Business Models). As far as I know, Porter and Heppelmann coined the term Smart, Connected Devices to separate their work focussing on the ‘changing nature of “things”‘ from the technology that enables and connects the “things”. Although they don’t refer to the concepts explicitly, Porter and Heppelmann elaborate on the business strategy and business architecture related to Smart, Connected Devices.

In detail they developed:

  • a definition of Smart, Connected Products,
  • a capability-based reference model for managing Smart, Connected Products,
  • a capability model for Smart, Connected Products,
  • a composition of ten new strategic choices in relation to Smart, Connected Products,
  • a summary of the change impacts in relation to the generic, high-level value chain and
  • a summary of the implications for the organizational structure of a company.

My personal takeaways related to Smart, Connected Devices are:

  • Software should be a key component of the product development cycle of a lot of industries and
  • Software architecture and development capabilities are mandatory to design and deliver Smart, Connected Products (see also Marc Andreessen’s essay Why Software Is Eating The World).

Views on the Application & Technology Architecture

There are a lot of reference architectures on the topic Internet of Things available. In particular, a lot of major software companies have some IoT-related product and/or service in their portfolio. However, if the focus is set on non-proprietary reference models, I recommend the deliverables of the European research project Internet of Things Architecture (IoT-A). Essentially this project delivered:

  • an in-depth architectural reference model,
  • definitions of initial set of key building blocks and
  • several accompanying deliverables like introductive guides and initial API designs.

All deliverables are publicly available. You can find a list and corresponding links in the section Smart, Connected Devices (aka Internet of Things) on the knowledge page Reference Models and Architectural Styles.

Do you know further resources which you consider as fundamental in relation to the topic Smart, Connected Devices or Internet of Things (IoT)?

Sound off in the comments!

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 Open Group Released a Business Reference Model for the Natural Resources Industry

The Exploration, Mining, Metals and Minerals (EMMM) Forum of The Open Group developed a business reference model that has been approved as an Open Group Technical Standard (see The Open Group Blog post here). The reference model focuses on the natural resources industry, i.e. the high-level business processes of different mining organisations dealing with all metals and minerals. It consists of a documentation describing the concepts and definitions of the reference model and a model poster providing an abstract one-page-view of the model. These deliverables are available for download from The Open Group Bookstore (see here).

The Role of the Enterprise Architect as a Sherpa

When thinking of the role of an enterprise architect, I came up with the idea of comparing the enterprise architect with the role of a sherpa. In government, a sherpa is a person who represents a head of state or government and prepares international summits, especially the G8 summit. Sherpas meet before the official summits to analyse and prepare the decisions or agreements. This reduces the effort required at the official meetings considerably.

In addition, the sherpas are generally responsible for elaborating on concepts and explaining them to the corresponding head of state or government. That means that they are responsible for the briefing of, and knowledge transfer to, the head of state or government so that this person is prepared for an official meeting.

The term sherpa refers to the Nepalese ethnic group, the Sherpa people, who guide and support expeditions in the Himalayas. In government, the term refers to the fact that sherpas pave the way for the official meetings and agreements. You could also think of the sherpas as bearing the brunt of work in preparation of the summits. The sherpas are assumed to be quite influential but in general they do not have the authority to make final decisions or agreements.

The role of the enterprise architect is very similar to the role of a sherpa in government. Enterprise architects work towards official meetings where architectural decisions are taken. This might be a meeting of the architecture board or any other governance body in charge of architectural decisions. In preparation of these meetings they elaborate on architectural options and any deliverables and artifacts that are required to evaluate these options. All architectural options should be analysed and evaluated upfront to the official meeting so that these meetings can be conducted efficiently. In opposition to the government domain, the architectural options should be evaluated objectively, based on clearly defined metrics/KPIs, i.e. architectural decisions shouldn’t be taken for purely political reasons (cp. ‘No Politics, Just Great Architecture‘).

Analogous to the role of the sherpa, the enterprise architect is responsible for the briefing and knowledge transfer to the stakeholder so that this person is able to make decisions within the official meeting. Depending on the stakeholder’s character and knowledge on architectural topics, this could require much effort and sometimes constrains the options you are able to discuss within the official meeting. In this spirit the enterprise architect paves the way for the official meetings and decisions. He/She bears the brunt of work in preparation of these meetings.

In summary, the role of the enterprise architect and sherpa are very similar. They take a back seat and focus on methodology, concepts, options, knowledge and facts. Both strive for an efficient and effective decision process and are intensively concerned with the exchange of knowledge prior to an official decision meeting. Therefore, they are quite influential but do not make decisions on their own. Nevertheless, enterprise architects should be objective in any case whereas sherpas often act with a hidden political agenda that is driven by individual or personal interest.

Mastering ArchiMate Edition I by Gerben Wierda

During The Open Group conference in Barcelona Gerben Wierda released his book Mastering ArchiMate Edition I. It contains an introduction to the ArchiMate language and documents his practical experience using the language within the financial domain. The book is available freely under a ‘begware’ license and I suggest that you donate or buy a licence if you use it commercially.

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.

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.