Software architects in the IoT
Following on from my colleague’s blog post “A new career profile for industry 4.0”, my post will outline what an IoT software architect does – and why I enjoy being one ☺.
Having built up over 30 years of experience in software development and architecture, I’ve seen just about every part of the business and experienced its highs and lows. I started off as a teenager, programming on my (still beloved) Atari home computer just for fun. From there I took computing classes at school, and got my degree in computer science specializing in artificial intelligence, which by then was at the height of its popularity. After graduation I started working as a software developer for a research institution and went on to work for a great many companies, focusing on projects and products in what today is referred to as “classic enterprise business.”
I’ve spent the past few years working as a software systems architect with a special focus on the IoT. I often get asked “what is so special about IoT solutions?”, and how my work has changed since becoming an IoT architect. Here are some of the challenges involved in creating IoT solutions and how these affect the role of the software architect.
Software architecture – and what it’s all about
This is the kind of diagram often drawn to illustrate what a software architect does. The steps shown are, of course, iterative and generally non-sequential.
- Collecting requirements and constraints: Requirements are usually defined and supplied by business stakeholders. They are about why a specific solution should exist. Businesspeople focus on the revenue they expect to create with the specific solution; IT departments on the other hand focus on costs, including the costs of IT infrastructure as well as the cost of operating, maintaining, and refining a software solution over many years.
- Create structure: All non-trivial (software) systems are made up of many components and functions that interact to produce the expected results as defined by the business requirements. To deliver a maintainable and extensible solution, it is important to structure systems so that subcomponents are cohesive, with a minimum of coupling so that future changes can be added more easily.
- Create cross-cutting concepts: Those concepts deal with requirements that are imposed on a system by the environment in which it is executed – internally as well as externally. These include technical concepts such as (audit) logging, error handling and recovery, security, and many more. There are also external influences, such as legislative requirements and certifications, which need to be taken into account when designing a system’s architecture.
- Communicate architecture: For a system architecture to be successful, it is essential that an architect can communicate it to and discuss it with all relevant stakeholders, including developers, IT departments, management, and of course business departments.
- Accompany development: In order for a system architecture to be implemented according to the “blueprint,” an architect will spend a significant part of her time with development teams, explaining concepts and reasons behind architectural decisions, analyzing and adjusting software designs, and being a part of the system test phase.
- Assess architecture: To ensure a system’s high quality over time, it is important to periodically assess its current state based on the underlying architecture. This is done to detect risks and technical deficiencies so as to then correct divergences that are inevitable when a system is worked on for years.
Since requirements change over time and new ones get added, architecture is not a “one-shot” activity, but has to be a process that continues until a system is shut down or replaced.
Architects balance the requirements and solution spaces
As an architect, my playing field is between the requirements space and the solution space. I’m always receiving requirements and constraints from the business side and translating them into technical terms that are then structured and assigned to components to be refined and implemented by the development teams. In the design and implementation phases, I receive constant feedback about technical implications that might create conflicts between what was intended and what is technically feasible or impossible to implement – due either to technical obstacles or time constraints.
In this area of conflict, it’s my job to balance both sides so that in the end, we can deliver a functional system that meets the expectations of the business side. The challenge is to decide if this is best achieved by refining requirements, reducing them, or even changing the structure of the software system –the goal being to solve technical obstacles today while keeping an eye on the issues of tomorrow. One of the great challenges of a “software architect in-between” is to always be taking proper care of existing systems. With new functionalities and technologies being added all the time, it’s easy to end up falling into the complexity trap. Over time, growing information systems tend to become inflexible, costly, and unreliable. They stop fulfilling stakeholders’ expectations and have the potential to reach a dangerous dead end.
This challenge becomes even bigger in the context of IoT solutions. Let me explain why.
What is special about solutions in the IoT?
Of course, there is no such thing as the IoT. IoT solutions come in lots of different varieties, help to solve problems in an even greater number of business sectors and domains, and don’t follow one single business model. From a technical point of view, the IoT is made up of three major components:
- sensors (and actors)
- connectivity and communication, including movement of data and its semantics
- data (storage and management)
Although just technical elements, future IoT solutions won’t be provided only by (device) manufacturers, communication providers, or cloud operators. As more and more increasingly connected smart things become available, more solutions will be provided by classic enterprise organizations themselves. These organizations are using the data and information originating from smart things connected to the internet to enhance their existing business. One clear knock-on effect is that over time the business contexts for connected things will become blurred. A professional connected power drill will no longer be just a tool, but will also play an important role in, say, logistics and CRM solutions. From the perspective of an IoT solution architect: This will increase the number of stakeholders who will have additional requirements and expectations that each IoT solution will have to fulfil.
In the classic enterprise, you tend to have one given business department, within a larger organization, that requires a software solution to solve a specific business problem. The architecture of such software solutions has some typical characteristics:
Typical characteristics of non-IoT software solutions
- Business context and requirements are limited and mostly come from one business unit within a larger organization.
- A clearly defined target environment in terms of runtime infrastructure, technologies, and user profiles that remain stable over a long period of time. Usually it’s an organization’s own IT department that defines the constraints for a solution’s architecture; remember, they’re responsible for running the whole IT infrastructure and ultimately have to account for what gets spent on it.
- Manageable number of stakeholders mostly from within an organization.
- Rarely more than one or two programming languages and data storage technologies in place, mostly one specific application server, one set of programming guidelines, one versioning system, one build server.
- One common code base, which makes it easier to conduct architecture assessments.
- In most cases, graphical user interfaces are for rich clients or web clients so there are hardly ever more than two UI frameworks involved.
- Changes to the software system are driven mostly by new requirements coming from one business department, most often triggered externally, e.g. through regulatory changes, mergers and acquisitions, market changes, or competitors coming up with new or better features.
What’s more, even if it’s never said explicitly, such solutions are “built to last” for a long time, often 10 years or longer. And since they keep growing over time, the main challenge is keeping a solution’s agility high (meaning its ability to be enhanced and maintained) while constantly adding business value to generate profit. Architects of such long-life solutions need to find a strategy for how to constantly improve their “inner quality” while still keeping them operational.
IoT solutions differ significantly in several architecturally relevant aspects. Some major ones are:
Typical characteristics of IoT software solutions
- Many IoT solutions are built in a context of not yet fully defined markets and business cases. To remain flexible and open towards what lies ahead, many organizations start small with limited feature sets, low number of users, and a handful of countries for roll-outs in order to keep initial investment low. Once such solutions become successful, they require flexible (elastic) scalability – and this has to be built in from the very start, as does a solution’s extensibility.
- Deployment of the relevant parts of a software solution happens across several distributed layers due to the major role hardware and bandwidth restrictions, integration of constrained devices, connectivity “gaps”, regulatory constraints, and mobile devices play in the IoT. Very often we see that in the end, data privacy and security requirements define where certain functionalities have to be executed and where data may be collected and stored.
- Then there are the great number of programming languages that are used – without a common code base, but with a multitude of employed build tools, testing frameworks, release cycles as well as certification procedures. At the end of the day, everything must run together smoothly.
- Hardware lifecycles and software lifecycles differ significantly and influence each other –impacting the time to market of an IoT solution, since it requires both the hardware and the software to be market-ready.
- Classic enterprise systems still play a role in most of the targeted solutions (ERP systems, billing services, CRM solutions, etc.) with all challenges belonging to their integration, and are still very similar to what we learned in the classic enterprise business.
- Serious IoT solutions have high requirements in terms of data storage and management. Thanks to the availability of NoSQL data storage, an architect can now make the best choice for managing relational, time series, document-centric, or other data with the sometimes challenging implication that single solutions can also suddenly become polyglot solutions with regard to data management technologies.
- User experience management has become a very important activity. Architects have to ensure end customers don’t encounter any problems with any relevant solution component (end-to-end, including software and hardware), particularly when it comes to smart home solutions, for instance.
- International laws and regulations have an impact on IoT products and solutions much more often than in the classic enterprise context.
- There are no standards in place yet in most of the IoT-related domains. At the same time, there are many competing and often conflicting activities going on internationally, which will ultimately affect the architecture of an IoT solution. Smart home activities across the globe are just one example.
- Although functional reuse across different IoT domains and their bounded contexts is assumed to be rather limited, we can definitely expect to encounter frequent overlap and interaction across what used to be domain-specific solutions. This will happen much less via semantically typed service interfaces than by sharing data (coming from sensors) that each solution then interprets differently in its own context.
- Now having lots of data at hand will require new technologies and concepts in order to derive knowledge and create ideas for new business based on what things can do.
My recommendation is: Beware of “Conway’s law”. It describes one of the greatest dangers for organizations in the IoT solutions area, arising through the parallel, often independent, activities of various business units. If not properly managed, this will lead to the implementation of similar (functionally identical) supporting domain functionalities and prohibit seamless operation of all solutions within a given environment. Things that previously operated in a limited business field can later play a completely different role. If we don’t consider this in IoT solution architectures, we may miss out on potential additional business value, ultimately resulting in lost business!
For the IoT architect this means: There are many decisions to make – each with an appreciation for what will be most effective. We need to have additional expertise in what up to now have been unfamiliar territories and markets. This is clearly a sphere of activity that requires advanced practical experience in the fields mentioned.
The IoT architect’s “breadth” of expertise
Let me explain what I mean by the architect’s “breadth”.
Although still benefitting from everything she has learned and experienced in the past, an IoT architect’s profile expands to take into account
- Many more stakeholders on the requirements side – including legal aspects, certification authorities, standardization bodies and consortia, 3rd parties and partners, the physics of things, etc. Techies beware: many things that are technically feasible must often be left out of a solution for non-technical reasons!
- Much more technology knowledge and, ultimately, implications in the solution space due to heterogeneous technology stacks even for a single solution.
- Uncertain business models which require flexibility of scale (number of users and connected things as well as in terms of features) and deployment (e.g. on-site deployment versus cloud-based solution).
- Massively distributed runtime environments with connections based on a multitude of different communication patterns.
- Many more interacting solutions to deal with when designing an IoT solution.
- Building blocks in an IoT environment become bigger while singular solutions still require fine granular structuring.
- Architects will interact closely with other architects from other solution spaces.
For me as an IoT architect, this means that the scope and field of activity has widened considerably. It’s now about much more than software systems. In my career, I have gained great insight into the day-to-day work of those in other technical disciplines, such as hardware manufacturing, sensor development, embedded software development, and mobile development. But today, I also work closely with teams from a variety of other business units and non-technical organizations, such as user experience experts, legal departments, and many more besides.
For anyone who likes change and continuous learning, regardless of the business sector or IoT domain, the life of an IoT architect can be full of motivation and enjoyment. In the long run, it’s about teamwork – both within your organization as well as across organizations. I confidently predict that, even if you are currently working in an organization operating as what I referred to above as “the classic enterprise,” you’ll sooner or later also be seeing IoT-related solutions entering your business domain – there’s no escaping the IoT!
Join the discussion: What other challenges do you think are out there for IoT architects?