Recently an increasing number of new variants are emerging around DevOps. This is of course a testament to the gravity of DevOps as movement. Each variant claims to be something new and shiny. DevQaOps, DevBizOps, DevApiOps and DevSecOps, to mention a few. It almost seems like there is a new variant coming each week which claims to solve all of your problems. Have you ever wondered why that is or what is all of this fuzz about?
When DevOps was first coined, the Tech world was not the same as it is now. The Tech domain is a rapidly evolving landscape filled with disruption and fads. The required skills & competences of ten years ago often no longer apply today. The advancements in e.g., cloud computing and microservices have created a demand for new skills and expertise. The team that applied DevOps ten years ago, shouldn’t look the same today from the capabilities standpoint. That is why one of the core pillars of DevOps is continuous learning, you’re never finished learning. As DevOps gained popularity, more and more organizations tried to jump on board the hype train. This meant that organizations with different levels of maturity started applying DevOps and make it fit to their reality. Like many other paradigm shifts before, applying a tried and tested framework and making it “fit-for-purpose” can lead to all sorts of conundrums.
Applying a best practice and making it “fit-for-purpose” without a deep understanding of it, is a recipe for disaster. Especially if your take of “fit-for-purpose” is to twist and turn tried and tested practices to fit your paradigm. An excellent satire piece was written about this by Ron Jeffries – We tried baseball and it didn’t work. It is often referenced in books and pieces of Agile and DevOps. DevOps includes all the required capabilities for software production. The DevOps cycle is simplified visual illustration for introductory purposes. It does not contain all the necessary information for adopting DevOps. Just because the cycle traditionally does not display aspects such as UX Design, InfoSec or Quality Assurance, it doesn’t mean that they are excluded from it.
One major factor leading up to the DevOps variants can be attributed to the ever-increasing shortage of tech experts. The digital disruption has created a reinforcing loop of higher demand than the supply. More and more often DevOps teams consist of junior level programmers and/or system admins. They have not had the opportunity to perfect their craft and are oblivious to the holism that is software production. One cannot address things they are not aware of. Unintentionally excluding critical practices from software production has led to the need to retroactively address them. There are no shortcuts to mastery.
The emerging variants are partly due to ‘Fear of Missing Out’ aka FOMO, and partly due to a real need to address arisen issues with incomplete or unbalanced adoptions of DevOps. The most recent variants of <X>Ops are a whole another story, but the Dev<X>Ops variants address specific needs in a given environment. Basically, the question is – which X is suboptimal in your team or organization and needs reinforcements? Dev<X>Ops isn’t the new DevOps, it’s DevOps with a single emphasis based on a dire need. If you are now considering starting DevOps, don’t start with Dev<X>Ops – the original is still the key.
- The X in Dev<X>Ops is okay, but do not try to come up with a new DevOps – the original one still applies.
- DevOps requires highly skilled experts, so be prepared to have both Seniors and Juniors in the team.
- DevOps is a highly capable and refined tool, but you need to know your way around it.
“If we don’t consciously acknowledge the power we have as designers to influence the future, and accept our responsibility, then we should not be in the job.”
From where I’m sitting, it feels that the world (or more specifically, society) is going through a phase of tremendous disruption, anxiety and change. I was born in 1968, making me 52 years old and I can honestly say that I can’t remember a time when I was so engaged/enraged by the daily news reports and events from around the world. Of course, COVID currently has a huge part to play, but for me, it’s a much bigger phenomenon. Do you feel it too?
These are the kind of hot topics on my mind in a typical day. Climate change, political polarisation, right wing uprising, left wing wokeness, Black Lives Matter, #MeToo, gender equality, diversity, identity politics, erosion of democracy, influencers, haters, big tech monopolies, celebrity culture, mass extinction etc, etc. I know, it’s heavy shit and overwhelming. It leaves us feeling hopeless, useless and disengaged.
As a designer these are also the things that make our job so interesting and relevant right? I’m optimistic at least that we can make a difference. After all, our responsibility as designers is to create a future we can believe in, and to directly solve the problems at hand for people, their communities and society as a whole. Our job is to help companies and organisations remain relevant in serving society throughout this disruption and additionally playing our part in keeping the whole network economically healthy at the same time. Big job for sure, with many unknowns, and a lot of responsibility. I need a pay rise.
I’d argue that as a designer of digital services, we actually have no choice about our responsibility toward these challenges. If we don’t consciously acknowledge the power we have as designers to influence the future, and accept our responsibility, then we should not be in the job.
Some important questions that I hear from designers in conversation and in the industry.
- Where do we stand as a design community?
- Where do I stand as a designer?
- What do I care about?
- Where should I focus?
- How do I get started?
- How do I stop designing stuff I don’t believe in?
- How do I do this on top of my day job?
Hard questions to answer I’m sure, but questions that are easier to answer if posed together as part of an organisation or company. If you work as a designer for a company, then the company has a responsibility to provide a platform for your values and mission as a designer. The best companies are the ones that align the community around a shared set of values and desired world view. A position that represents the overall impact they want to achieve in the work they do together with their customers. Maybe this is a luxury, but I think not. More and more companies are recognising the needs of a new generation of employees who value meaningful work and positive impact as the main drivers for their careers and search for employment.
I’m personally inspired and activated by the brave and bold moves the Gofore brand has taken recently, with a new brand strategy and promise. Our promise being “Pioneering an Ethical Digital World” with its strong focus on holistic sustainability. In all this chaos, this position takes a clear stand and represents the kind of future we at Gofore believe in and want to build. The kind of future we come together as designers to create, in collaboration with our like-minded customers in both the public and private sector.
To do this in practice, we are rapidly developing our methods and tools and hence the birth of Good Growth as a framework for this approach.
Within Good Growth we have multiple tools to help us address the challenges from three angles, People, Nature and Business and to specifically answer to the ever-changing needs of our society, we have developed the specific methodology “Design For Everyone”. This toolkit helps us and our customers to engage with society in a deeper more meaningful way and to understand better what makes people tick now and in the future.
That’s good news for companies and public sector organisations. They’ll need to keep a keen eye on their relevance in a market where social media can literally kill a brand overnight and new generations of opinionated activists are progressively developing society at a pace that far outstrips the clock rate of your average institution or corporate entity.
So, with all that said, I think it’s a great time to be a designer. The design opportunities that are presented to us are as exciting as they are challenging. Stay tuned for more news on our Good Growth model and in particular the Good Growth tools that will help us get there.
Check out my earlier blog introducing Good Growth
The X-Road Security Server Sidecar is a Docker container optimized as a provider or consumer X-Road Security Server for being deployed next to an Information System. The Security Server Sidecar is intended to be running in the same context (virtual host, Kubernetes cluster, etc.) where the Information System is running. The containerized approach makes running the Security Server more cost-effective and better suited for environments where Information Systems exchanging data using X-Road are already running in containers. The Security Server Sidecar was originally developed for the Finnish Digital Agency and is published as free MIT-licenced open source component through X-Road data exchange platform managed by the Nordic Institute for Interoperability Solutions (NIIS).
With Sidecar, the Security Server installation process becomes much simpler than setting it up in dedicated server hardware, requiring only an existing installation of Docker on a Linux platform. Windows and MacOS are not officially supported, but they may be used for test and/or development purposes.
The X-Road ecosystem member can run one of the several Security Server Sidecar images published on NIIS Dockerhub repository. Some user-defined parameters are required, such as X-Road database and Admin UI credentials and software token PIN, to ensure the configuration for the Security Server Sidecar running on the container is unique. During the first run of the Security Server Sidecar container, the entrypoint script generates unique internal and admin UI TLS keys and certificates and configures custom admin credentials and software token PIN code for the user.
The Security Server Sidecar provides the option to configure an external database instead of the default local one by providing the remote database name, port and superuser credentials as parameters. It also supports a variety of cloud databases including AWS RDS and Azure Database for PostgreSQL. This deployment option is useful when the cloud-native database is the preferred choice.
The X-Road ecosystem member can make use of different Security Server Sidecar Docker image versions. Each image version installs a custom set of pre-built X-Road Security Server modules. Depending on the image version they want to use, it will install the basic X-Road Security Server modules or additional ones. For example, the 6.25.0 version of the Security Server Sidecar includes message log, operational monitoring, and environmental monitoring modules, whereas the 6.25.0-slim version does not include them. In both cases, the Security Server Sidecar can be used for both consuming and producing services, although the slim version is recommended for the service consumer role. Additionally, there are some country-specific configuration versions available, such as the 6.25.0-fi version including the Finnish meta-package configuration (currently the only one).
One of the advantages of using the Security Server Sidecar is that it runs alongside the client’s or service’s Information System on the same host but in a separate container. Security Server Sidecar container can serve one or more Information Systems on the same cluster. Later, the Security Server Sidecar can be scaled up and down independently from the Information System in the cluster to accommodate the fluctuation of requests. However, in this deployment scenario, the footprint of the Sidecar container is relatively high compared to the footprint of average containers and it must be taken into consideration for dimensioning the cluster size appropriately.
When Security Server Sidecar is run in a production system, it’s not acceptable to have a single point of failure. Fortunately, the Security Server supports high-availability configuration via internal load balancing mechanism. This configuration is natively supported. For the purpose, user needs to configure several Security Server Sidecar containers with the same combination of member/member class/member code/subsystem/service code. The X-Road Central Services will then route the request to the Security Server Sidecar container that responds the fastest.
External database and volumes
Another benefit of using the Security Server Sidecar is that it can use either a local database running inside the container or a remote database running externally. Since the Security Server is a stateful application, it is strongly recommended to configure the Sidecar container to use volumes and external database to persist information outside the Security Server Sidecar container in a production environment so that the Security Server Sidecar configuration is not lost when the container is destroyed. Docker volumes allow using the same configuration for several Security Server Sidecar containers, making it possible to keep the configuration even if the Security Server Sidecar container is removed or updated. The Security Server Sidecar can easily be updated by creating a backup, running the image with the new version, and restoring the backup or re–using the volume with the previous configuration. A major version update may require changes, so before updating the Security Server Sidecar, it is always advisable to check the specific version release notes for the version update.
From a security point of view, Docker guarantees that applications running on containers are completely isolated from each other. However, running the Security Server Sidecar in a Docker container has some security risks derived from the separation of the application layer and the infrastructure layer. The user should carefully review some of the Docker security best practices for securing the Security Server Sidecar container. A comprehensive Security guide can be found on the Security Server Sidecar documentation, which describes the most relevant recommendations to avoid common security pitfalls.
To avoid unrelated services or containers running on the same host to reach the Security Server Sidecar, a user-defined bridge network should be employed, allowing only containers attached to that network to communicate with each other. It is also strongly recommended to store configuration files with sensitive information into volumes outside the Security Server Sidecar container.
More information about sidecar:
Finnish Digital and Population Data Services Agency: A new highly requested sidecar option
How to tell if your business is Agile? How to ask from a C- level people whether their organisation is Agile?
From small to big
There are tons of advice on how to measure agility at a team level; Velocity, Burndown, Planned vs Actual, Work in Progress, DevSecOps, etc. All these measures aim to estimate and optimize the long-term work capacity and work quality of a team.
However, when assessing overall Agility at an organisational level, we need to take a step back. The main idea of a business is to deliver maximum added value to stakeholders. Therefore, we need to bring our attention from “HOW” to “WHAT”. The main idea of Agile is to accelerate the decision-making-and-learning loop. The Decision Driven Organization by Harvard Business Review 06/2010 had a Quick Test of Decision Effectiveness, which describes nicely the Agile mindset:
- Quality: When looking back on critical decisions, you find that you chose the right course of action most of the time.
- Speed: You make critical decisions much faster than competitors.
- Yield: You execute critical decisions as intended most of the time.
- Effort: In making and executing critical decisions you put in exactly the right amount of effort.
Without leadership, an organisation slides down to an ad-hoc Limbo. While being agile, the organisation still needs a strategy, a long-term vision. Parallel, you must avoid mid-term planning. Mid-term planning turns into a middle-management, where both the long-term vision and the short-term agility is lost. Mid-term planning is a waste.
In Agile it is OK to fail. Failure means learning. Agile is about embracing the scientific approach: hypothesize, test, analyze and decide to preserve or pivot. It is OK to run multiple hypotheses’ in parallel with the ‘Least-fit’ principle instead of selecting a single idea and running with it. Dare to start parallel strategic change projects and after some time kill the failing ones. A/B testing is a fast way to learn more.
Bureaucracy tends to fulfill all the gaps. Bureaucratic managers will always figure out new ways to measure, manage and control. Bureaucracy never leads to a better business.
Bureaucracy lives from the fear of uncertainty, but it will not fix the uncertainty.
Uncertainty is a byproduct of complexity. You can reduce both bureaucracy and uncertainty by making information transparent and keep the decision making as close to the operations as possible. As Scaled Agile Framework states, continuous learning focuses on relentless improvement, where improvement activities are fact-based, and increase the effectiveness of the entire system instead of silos.
Management is about making decisions. Making hard decisions is difficult. A weak manager easily lists a dozen of things where you must focus next. “Let’s first focus here, and then here, and let’s keep our options open also here”. This is slack decision making and a waste of energy. A strong manager lists only one thing. “Let’s focus here and say ‘No!’ to everything else”. In an Agile mindset, you focus a period of time on the thing that matters the most. Then you reflect and learn.
Reductionism means that you can solve a problem by breaking it down into smaller parts, solving the small problems, and then putting it all back together again. This works in a simple environment. However, the assumption that past experience leads to a deterministic future solution is valid only within an ordered system. With enough data, you can find a correlation between anything. “People drown when they eat more ice cream”. But this does not imply causation. Problems arise when the work is based on wrong assumptions. In a complex environment, you need trials, where you break the system into components, study their interactions and create a holistic model of the system as a whole. The situational awareness model helps you with such systemic decision making.
Small investments can be made into safe-to-fail experiments in a balanced portfolio before committing more resources. Traditional enterprise control mechanisms doesn’t work with Agile mindset, while traditional annual budgeting doesn’t support the fail-fast principle. Still, you can still make agile decisions along the way about what to do with the budget.
Even an Agile organisation needs a fast re-planning mechanism, which triggers if a positive opportunity or a negative risk materializes. Re-planning means you stop the ongoing planning cycle, re-plan a new cycle and keep going. As long as the long-term strategy is viable, you need to reset only the latest short term cycle. You are able to make fast decisions concerning the short term direction.
Again, at the event of sudden change, a weak manager tends to re-plan everything from long term strategy to mid-term plan and finally to short term actions. This is slow, slobby and useless. At the event of a sudden change, you need to make fast decisions. Fast decisions are a sign of resilience. Fast decisions enable you to exploit sudden opportunities and avoid quick threats.
Embracing Agile by Harvard Business Review 05/2016 states “Some executives seem to associate agile with anarchy.” While an Agile organisation can make fast adjustments, the wider direction is still based on a long-term vision. Often the vision translates into a short-term roadmap, which customers can use safely to plan their own activities. In addition, the roadmap prevents individual teams from being siloed off. Vision and roadmap empower decentralized decision making by enabling everyone to work towards a common goal.
- Have a transparent vision
- Near term future is churned into a prioritized backlog
- Most of the time is used on the items at the top of the backlog
- Measures are transparent and they provide additional value for the stakeholders
- Seek automate everything and have an effective DevOps running
- Constantly innovate on how to deliver value faster for your stakeholders
- People feel safe and they trust on each another
- People start their own initiatives. The swarm intelligence produces new business opportunities
Have an ability to have difficult conversations.
If the article got you interested, scared or angry, please do not hesitate to contact us. We are here to help.
At the beginning of November, a group of Gofore designers and developers working in various design system projects gathered together to share their experiences. Participants from four different projects shared their experiences on tools they use, best practices, and other things they have learned along the way.
In this blog post, we’ll take a closer look at the tools used for designing, developing, and documenting design systems.
Design systems usually provide some kind of design library or style guide for UI/UX designers working on product features and user flows. The chosen for producing this design library must of course align with the tools used by the designers.
Design and collaboration tools used in Gofore Design system projects
It is not surprising that three out of the four Gofore design system projects that shared their experiences use Sketch. When Sketch was first released in 2010 it was considered the game-changer in the user interface design field, and since then it has established a position as an industry standard. Sketch has a solid ecosystem of plugins that help to expand its core features and automate tasks. However, in recent years Sketch’s dominance has been contested by new tools with fresh ideas.
Sketch’s main competitor Figma has raised interest in the design community with its all-in-one approach, emphasis on collaboration, designer-developer handoff and design system-oriented features. Also, the way Figma’s handles styles is more flexible and the layout behaves a bit more like HTML box model than Sketch’s – something you might expect from a tool that is purpose-built for designing user interfaces. While Sketch is MacOS only, Figma is web-based, and also provides a desktop app for both Mac and Windows.
One of the alternatives for Sketch is Adobe XD. For now, XD is generally not considered to be a prime choice for design systems, but since Adobe has a stronghold virtually all other design tools, it can’t be counted out of the competition yet.
All in all, there are strong signs that Figma is already undermining Sketch’s dominance on the market. Even though all of the four design systems have initially used Sketch, two of the teams have at least considered the prospect of switching to Figma and one has already made the switch – and the switch has reportedly made the consistency of user interfaces better.
Design collaboration and versioning
One of the main reasons why Figma has made a foothold on the market is its emphasis on easy collaboration.
True collaborative workflow with Sketch can still be a bit cumbersome, even though Sketch launched their own browser-based file sharing and collaboration tool Sketch Cloud at the beginning of 2020. Its functionalities are still fairly basic – for example, the file inspector tool is still in beta – but it is definitely a step in the right direction.
So far Sketch’s shortcomings in basic collaboration features have usually been patched with Abstract – a separate design library tool that pairs with Sketch through a plugin. It brings a git-like version control and branch-based workflow for designers and enables reviewing, commenting, and inspecting design files. Abstract also helps to share library files with product teams, making it a prime tool for design systems. Like Sketch, its desktop app is available only on Mac, but it also provides a web-based interface.
Although Abstract is a great tool that has fundamentally changed the way designers can work together, it doesn’t always play nice with its counterpart. The fact that the whole collaboration workflow depends on two separate tools made by different companies, makes it more vulnerable to compatibility problems. From this perspective, Sketch’s strategy to expand its core features with plugins turns from its best feature to be a burden. This is the pain point Figma aims to solve with its built-in collaboration and communication features.
Figma does not support git-like branching workflow like Abstract, but the Professional plan offers an unlimited version history and sharing design system libraries for the team. The pricier Organisation plan also offers really promising design system analytics tools for measuring design system adoption and usage. This is hard to accomplish with Abstract, which only allows inspecting library dependencies file by file.
Time will tell how Sketch Cloud will develop and can it even Sketch’s odds in the competition with Figma.
Development tools and frameworks
Providing reusable and customisable components for developers is the basis of all design systems. Like design tools, the technologies design system components are built on is dictated by the technologies used in the actual products.
Front-end frameworks used
Among front-end-frameworks, the winner is clear: all four of the design systems are built with React.
Third-party libraries like Styled components are also commonly utilised to make component development easier and faster, and to help for example tackle tricky functionality and accessibility issues. However, even though these libraries can bring short-term benefits and time savings, most design systems tend to aim to keep dependencies to a minimum to avoid problems rising when the system grows more complex. Building design system quality components – especially accessible ones from the ground up is more time-consuming, but when the design system starts to grow in scale, managing dependencies can start to weight down the process and bring with them unexpected issues.
Code repositories and development environments
Quite often organisations identify the need for design systems when product development has already been ongoing for a while. Product teams have already established development workflows and environments and a design system is developed as part of these existing environments to bring consistency and reduce redundancy in development work.
In the tools used for versioning and distributing design system repositories projects are two-fold. Two of the projects use GitHub. Both of them have shared their design system open source, so Github is an easy solution for code collaboration. Two of the projects use Azure DevOps, a part of Microsoft Azure cloud computing services which provides more comprehensive toolkit for DevOps and project management.
Component development / catalog platforms used
Most design systems also use development environment tools like Storybook and React Styleguidist. How these tools are utilised in the workflow vary between projects. Usually, they are used as a platform for developing and testing UI components, and as a component catalog for developers showcasing components and their functionalities, and documenting available properties.
Without documentation providing principles and guidelines for using the building blocks both in design and code, the design system is only a pile of components without a clear purpose.
The best tool for a design system’s documentation needs depends mainly on who should have access, and who should be able to add content to it.
Documentation platforms used
Many design systems maintain a public documentation website – especially open source systems. Even if the actual components and design assets are kept private, a public documentation site can act as a marketing tool showcasing the organisations design approach.
Three out of the four design systems had a custom made public documentation site – all built on the open source static site builder Gatsby or some more documentation site specific variation powered by it, for example docz. Other open source alternatives are for example Docusaurus and and Cupper, both advertising themselves to provide good accessibility – which docz has some serious issues with.
If the design systems is private and used within a single organisation, the documentation can also be managed in the organisations internal workspace like Confluence. One of the four projects used confluence for the entire documentation, one only for keeping record of design system related processes that didn’t belong to the main documentation site.
Both approaches have their pros and cons. A custom site gives the team free hands to build the documentation as they see fit: embed live demos and component playgrounds to documentation, automate token listings etc. But compared to Confluence, Gatsby site needs more work to set up and maintain. It also demands at least basic coding skills from content editors, since documentation is written in markdown and occasionally HTML or React. And, like any dependencies, the site builder can also become a burden. Gatsby in it self is popular and well maintained, but for example docz is not supported anymore, so it has many open issues that have been left without fixes.
The benefit of keeping documentation on an internal platform is that it is easy to set up and maintain, and it’s easy even for non developers to add content. But Confluence is not exactly made for this kind of use, and its features can become limiting. For example it does not provide many possibilities for automating, integrations or live component demos and playgrounds, so more documentation work has to be done by hand.
For this reason, the choice of documentation tool is surprisingly important one. Up-to-date documentation is crucial for the success of the design system, and If documentation is too laborious to produce it can become stale, loose its purpose and make the whole design system a dud.
Consequently, new documentation platforms have started to emerge on the market. Services like Zeroheight and Frontify aim to combine the flexibility of custom built documentation sites with the ease of content edition of workspace platforms. They also provide powerful integration tools with common design and development tools. Zeroheight and Frontify don’t come free, but can help saving considerable amounts of precious time and resources spent on documentation tasks and make the documentation more relevant and easier to digest for designers developers. Services like these, might well be the next big thing in the field of design systems.
Tools by project
The choice of tools can make or break a design system. Tools that do not fit the needs of designers, developers and other stakeholders can hinder the systems growth and adaptation. Tools are also constantly evolving, but changing tools along the way is tedious and should not be made based on trends only.
This is why the tooling of the systems should always be carefully considered right from the start, based on the needs of the products and teams it is built to serve.
Read also: The recipe for a successful Design System
At a classic car event in 2015, I met someone with an impressive collection of cultural heritage on four wheels. When I asked: “What is your daily drive?“, he whispered to me saying that he drives a Mitsubishi electric and would never go back to combustion. To me, that was an unexpected answer. Among car enthusiasts, electric cars had been considered as sexy as long underwear. Impressed and shocked at the same time, I too began to get interested in electric cars. Eventually, while we were working on designs for E.ON charge poles, I took the opportunity to buy a second hand fully electric car for “business reasons”. Have you ever experienced driving an electric car? While it is not the immediate sensation of “wow” like your first motorbike ride, it quietly and slowly takes over you. The acceleration will make any Porsche driver jealous when racing you to the next set of traffic lights. And, to no surprise, it is as easy to operate and maintain as a hairdryer.
I enjoyed my time as an “early adopter“, though it seemed that everybody else knew better than me why this cannot be the future: “Don’t forget the rare minerals in Congo are almost depleted!” and “I heard it’s dangerous to grab the door handle when it’s raining!”. As with many topics, forwarded and unevaluated messages on social media are the main source of “information” to a substantial amount of people.
I attended the electromobility congress “Hypermotion” recently and a presenter thought he would surprise the audience with the fact that “Surveys show that 70% of electric cars are being charged up at home!”
Excuse me? If you would drive electric you would know that there is mostly no other opportunity, as the few charge poles available to us in the cities are permanently sieged.
In the beginning, I figured a public charge point would be a place to meet nice people with the same attitude; a place to chat about sustainability or new technologies. But when access to the ever scarce source of energy is contested, things are quite different…We’ve all seen people reserve deckchairs at the hotel pool in the early morning, regardless of whether they actually show up. I can confirm that the same strategies are being used at the charge point. “Someone else might take it if I do not.”
Here comes a twist: the true benefit of space at the charger is not to improve the battery status of your car, but rather the unlimited parking time for free. Engineers gave us fast DC charging, allowing you to charge up to 80% in no more than 30 minutes. But half an hour is too long for a cigarette break and too short for a shopping tour downtown. That is why the slow AC plug is so popular and desirable.
There are some reasons why they haven’t built as many charge points as would be required. One is the measuring of electricity.
Shouldn’t measuring the amount of used electricity be as easy as it is at home? Sorry, we had to reinvent it and that takes time in good old Germany. For the time being, we have to wait for more public chargers that are compliant with the specs of Physikalische Technische Bundesanstalt.
Whenever technology is about to change, we tend to focus on the issues we will face. And while that can be a healthy attitude, I wish everybody also considered the advantages that justify overcoming those challenges. We got used to petrol and diesel engines, as we have those in operation for 100 years already. Go ahead and look inside one or take one apart, you will be amazed at how complex they have become and how difficult it is to get them to run. Hundreds of metal and rubber components, all running in a dirty bed of oil. A complex organism with countless weak spots and generally unsustainable behavior. All of this has been made completely obsolete by a small, silent, and clean motor with no need for maintenance.
Electromobility is new and it is fantastic. Let us develop this new and sustainable technology and the infrastructure hand in hand as fast as possible. We at Gofore are convinced that this is the future on the way to the zero-emission goals. We have been working on various related projects for years: we designed ergonomic public chargers, we developed state of the art software for charge platforms and we will be happy to make further contributions.
We said we had information security,
But were asked about its maturity.
So we took a route to remove any doubt,
By certifying it for tendering surety.
That’s the situation we were in toward the close of 2019. We had our information security management system (ISMS) only somewhat documented and our onion rings of protection still needed some growing. When prospective customers asked for our information security credentials, we provided these. But often they were unimpressed. They further inquired about our security practices, security risk management, and level of awareness. And finally, they asked were we information security certified. Or an application for tender asked this simple question “Is the company ISO 27001 certified?” No meant that we were already at a disadvantage before the tendering competition even began. Or in some cases it meant we were not eligible to even apply. Clearly this could not continue; we had to turn disadvantage into opportunity.
It started with top management accountability and commitment
In December 2019, the Gofore Security Team rose to the challenge and proposed to the management team, with evidence of tendering disadvantage in hand, that our ISMS should be formalised and certified to meet customer expectations. This was the critical first step because such an impactful company-wide project categorically requires the sanction, commitment and sponsorship of top management.
We proposed that *ISO27001 should be the internationally recognised standard to certify to. Top management approved the green light to start the ISO 27001 project on condition that we, quote CEO Mikael Nylund, “don’t do anything stupid”. The project was overseen by Chief Information Security Officer Jani Lammi, led by Secure Design Consultant Niall O’Donoghue who advocated for ISMS certification, with Security Consultants Tapio Vuorinen and Akseli Piilola as specialist project members.
Next, we scoped the ISO 27001 project. This was a critical second step (after top management approval) and so, to avoid doing “anything stupid” already, we delved into sources of advice and past experience that warned too wide a scope had doomed many organisations’ first attempts at certification. We really didn’t want to join that wall of shame. When the scope was agreed, it simplified identifying associated tangible and intangible assets, and that in turn simplified identifying stakeholders i.e., those with a vested role, responsibility, or interest in how the ISMS protects the assets within scope they utilise. Keeping within the certification scope was essential for formalising our ISMS benchmark that other company sites could aim to comply with.
That human connection called communication
Another pitfall we were careful to want to avoid was miscommunication. This was a delicate balancing act because the two leading causes of miscommunication in business are lack of communication whereby no one knows what’s happening, and excess communication whereby too many messages lead to key take-aways being missed or buried. We aimed for a cosy middle way with monthly stakeholder update meetings, several strategically issued awareness-raising broadcasts, a survey, and direct contact to key stakeholders.
Direct stakeholder involvement was crucial for information security risks identification and assessment. ISO 27001 is heavily based upon identifying relevant risks and applying human, process or technical mitigating controls to ensure sufficient asset robustness and resilience against ever-present threats. Risks identification and controls implementation was a time-consuming activity.
Soliciting employee (aka Gofore crew) opinion and input were achieved by means of a security pulse survey since, after all, crew are the company’s most valued asset, so their observations and recommendations must be taken into account. In a company with a flat organisational structure and a culture of transparency and self-determination, crew acceptance of and compliance with ISMS improvements is essential for effective security in practice.
Preparing for ISO 27001 certification consumed a lot of time and resources not only from the Security and IT teams but also from key stakeholders. Keeping the many ISMS facets being improved under control required proactive timely planning, and a ticket-workflow methodology, and fine-tuning along the way. Focusing on the critical and prioritising resolution of non-conformities and long-term ISMS deficiencies was central to getting things progressively done toward compliance. An internal audit, pre-audit and stage 1 audit were concurrently project delivery targets and progress checkpoints.
The project began in December 2019 and it ended in December 2020 with the certification audit which occurred over four days with thirty-two interviews and four office site tours. We achieved ISO 27001 certification, which probably confirms that we didn’t “do anything stupid” and now we can bask in the celebration of our achievement for a while. But in celebrating, we must not forget why we did this project. The top four reasons we certified our ISMS were 1. to raise the level of security awareness in the Gofore crew, 2. to evolve the ISMS to a condition expected from a digitalisation company, 3. to control identified security risks the company constantly faces, and 4. to win more customer project tenders.
The project is over but the program continues
Security is sure to fail if its kept separate from everyday business. Security cannot be bolted on either humanly, process-wise, or technically, it must be integrated and seamless as sensibly possible. So, the ISMS program must continue as a normalised aspect of everyday business. After the certification audit, business stakeholders and crew are still as relevant for ensuring ISMS effectiveness, and so the collaboration continues. There are more risks to identify and controls to implement. There must be ongoing security awareness to ensure newcomers and contractors comply with our information security policy. An annual review and audit of our ISMS must be conducted. Our ISMS must not regress, it must progress as business progresses.
Niall O’Donoghue on behalf of Gofore
You will find Gofore listed as ISO 27001 certified via https://www.kiwa.com/fi/fi/palvelutyyppi/sertifiointi-ja-arviointi/sertifikaattihaku/
* ISO27001 is a security standard that provides a framework for establishing, implementing, operating, monitoring and maintaining an ISMS. ISO 27001 is extensively accepted as the highest security standard in the information and communications technology industry for verifying the efficiency of an organisation’s overall attitude to security.
Many different types of organisations are today increasingly adopting Design Systems in order to achieve maximum efficiency in their digital development. However, Design Systems can face challenges brought by the effects of business transformation, corporate merging or brand identity changes. How can Design Systems be built to survive the potential increasing complexity and challenges of the evolving environment where they belong?
We already know that Design Systems evolve constantly with the products they serve and due to this fact they require a flexible structure in order to be maintainable and scalable, but we also believe that there are other valuable points to consider. In this article we will go through the points we consider as main ingredients for a successful Design System.
Things to consider from the early start
Typically a Design System is born from the initiative of a business unit or a department managing different product development projects, aiming to prevent wasting design and development resources by introducing reusable frontend coding.
Although setting up a common frontend development library and UI kit can somehow improve consistency between isolated teams, the real efficiency of a Design System is ruled by other factors that enable and encourage true design and development cooperation between the teams involved. One of the most important of these factors is inclusion. It is a wise step to bring together all designers and developers from different teams and make them share their encountered issues, questions, doubts, suggestions, and opinions. Giving everyone a voice will increase a feeling of inclusivity and a sense of ownership, which will result in more involvement, synced work, and efficient collaboration.
Tip: Get in touch and get to know the users of the Design System and their needs. Schedule recurrent meetings with a collaborative topic agenda and structured facilitation for product team owners, designers, and frontend developers.
In large or merging organisations, the Design System might need to be introduced and adopted by new business units and their stakeholders, and they will only adopt it if they understand the value of it. For this reason, it is important to consider the Design System as a product from the beginning, requiring a clear strategy that defines:
- Foundational values – In which values the Design System is based?
- Users and needs – For whom are we doing it?
- Product ecosystem – The potential products/teams we can serve
- Team – Who has the ownership? What are the resources?
- Vision, mission and goals – Why are we doing it?
- Product features – What is included or delivered?
- Value proposition – What are the benefits of using it?
- KPIs – How will the impact be measured?
- Roadmap – An iterative and updated long-term plan
Tip: Start by defining assumption based user personas by first gathering through collaboration boards the needs from all the teams involved and consolidate them into the needs of each user persona of the Design System.
An atomic design approach benefits flexibility and scalability of components into new requirements. The tokens and components of a well-structured Design System are easier to adapt to challenges brought by the new product requirements or new brand identities, enabling the maintenance of consistent user experience across different products.
Tip: It is good to keep flexibility in mind from every perspective, one example is to think about the naming structure of the tokens, eg. avoiding naming conventions that include color names relating to a certain brand identity color palette.
Templates, contribution flowcharts and design principles
Component documentation is not enough to bring consistency between product teams. Because designers can interpret and use information in many different ways resulting in an increasing amount of solutions for similar purposes, it would be convenient to document templates including already coded components in order to support the consistency of design.
Before the creation of new components, it is useful to confirm that there aren’t other existing coded components that could be used or adapted to new product requirements. This could be done by following a flowchart for component creation and usage. Since most of the initiatives for new components come usually from product design, it is convenient to start the flowchart from the design perspective considering differing option paths towards development stages.
The consideration of good design practices to achieve a more consistent experience across different products can be consolidated and promoted within the Design System by defining and documenting a set of design principles. These principles should be based on the foundational values defined within the strategy and they should include some detailed examples of their application in order to serve effectively design teams.
Tip: It is convenient to create and validate flowcharts, principles and other guidelines in collaboration with all designers and developers involved in the Design System, that will be the way to ensure that everyone will adopt and apply them into their work.
Tools and technology
The usage of too many design production and documentation tools adds complexity and makes it difficult to follow the consistency of design and delivery of technical specifications. It is important to research tools available in the market and opt for products that will allow consolidating as many features as possible within a single environment.
Tip: There are some good tools consolidating many features in a single package. Consider studying these tools and give the team the chance to decide on the most convenient and efficient option.
Clear and efficient documentation impacts production velocity and avoids siloed decisions. On a large scale this translates into saving the efforts of repeating tasks and duplicated work, saving effort and resources.
There are more options today for Design System documentation platforms, but perhaps one of today’s most valuable features to consider for a documentation tool is the ability to showcase live coded examples. Is very useful to see and try components in action already from the documentation. This will allow any user to test eg. the responsive behaviour of the coded components.
Custom platform solutions give designers the ease to test lively the reliability of components when eg. changing contents or language version. This could ease the finding of issues on a design that might be good to fix before proceeding into final product production.
Tip: Designers and developers should come to a common understanding of what would be the best platform tool to enhance their daily Design System use. Which features are the ones that will really boost their efficiency in production?
Leadership and communication
A Design System cannot succeed without effective communication and good leadership. A successful Design System equals a community of designers, developers and other product stakeholders sharing commitment in achieving maximum efficiency of performance in product development, usability, accessibility and improved user experience. A positive atmosphere promoting trust, psychological safety and transparency are essential to building respect, collaboration, inspiration and commitment within all the parts involved.
Spread the word. Opening communication channels to invite and keep stakeholders updated on new features or promoting transparency on decision making are also convenient practices, but they might not be efficient enough without some sort of planning. Excess of information or repeating communication can easily turn unnoticed or ignored. What are the important things to communicate and to whom? Which will be the channels to be used for different purposes? These can be some questions to think about when making communication decisions.
Tip: Executing more planned communication can enhance the impact on the interest and involvement of stakeholders.
Dedicated development resources
All the previously mentioned things can become basically worthless without the required amount of dedicated development resources (Design System developers) or appropriate distribution of the development work (contribution from the teams). It would be suitable to have at least one dedicated developer within the team, who could plan, document, coordinate and lead the frontend work related to the Design System.
Tip: It is important to consider and evaluate in advance the potential risk of running out of development resources in case there is a significant growth of frontend requirements.
A great part of the success of a Design System relies on how well it achieves to integrate stakeholders into a collaborative community, sharing common goals, principles, and open communication by defining a clear strategy.
The use of documented decision-making flowcharts together with a set of defined design principles can effectively support product teams to achieve a better, consistent user experience.
In order to enhance the flexibility and scalability of a Design System, it is important to build its components based on an atomic structure and to use descriptive token naming conventions that are not structured by elements of a specific brand identity.
Ensuring enough frontend resources and work distribution it is crucial to respond effectively to product development needs with the required speed.
Read more on Design Systems:
DevOps has become the new de facto software development framework. Just like Agile years before, DevOps was adopted by teams. These teams were searching for ways to scale continuous integration into continuous deployment and delivery. Combining the development and operation of software into a single responsibility area is no small task. Scaling DevOps from individual teams to enterprise-level increases the complexity and difficulty by magnitudes. Organizations that strive for enterprise-level DevOps require a paradigm shift from traditional ways of organizing to a product and value stream-based approach. Basically, the Lean-Agile principles need to be spread left and right into Business and IT.
The product approach
Products have unique characteristics compared to other similar entities. Most notable of these is the product life-cycle, which requires forward-thinking, brutally objective examination i.e. life-cycle management. Traditionally we’ve viewed products as commercial entities, but a product can be anything, big or small, with a specific value proposition and a managed life-cycle. A product can be an internal operating system such as a CRM or something as small as a test automation solution. Shifting from traditional IT into product management requires an end-to-end mindset. Organizing your IT systems and platforms into a product portfolio is the first step towards adopting the enterprise DevOps.
The value stream approach
The Toyota Production System, widely referred to as Lean, approaches the organization of work as value streams. One of the core principles of Lean is to organize people around customer value-adding work, instead of spreading the work across an organization i.e. a value stream. A Value Stream Map describes the flow of customer value as the required steps and information to produce the expected customer value. Combining the Value Stream approach to the Product Approach creates a systematic way to focus on outcomes: Product Value Streams. However, the Value Streams of digital products are not the same as the value streams in a factory. They are more like networks. Interconnected nodes with the built-in capability to work around problems, instead of stopping the line once an incident occurs. To harness the benefits of product value streams, we need to understand the interconnectedness of the products and their value streams as a network. These connections need to be managed carefully to e.g. avoid suboptimization. Organizing into product value streams is an organisation-wide exercise that requires mindful engagement from every stakeholder.
Scale DevOps to enterprise level by
- Start thinking in products to make use of robust practices like life-cycle management
- Organize into value streams to organize people around work focused on customer value
- Understand the interconnectedness of your product value streams to manage your value stream network
Would you like to adopt agile and lean methodologies? Read more here
Sustainability in the development of digital services includes also the project, and consequently, relates not only to the product but also the process and the people within. Therefore, making positive impact through sustainability in the development of digital services should satisfy the following. The software should be green, it should be perdurable, it should bring social added values both for its users and technical community, bear a long-term profit, have a low cost, help evolving organization intellectual capital, and make sure that it is comfortable for the developers to work with as well as that it helps to evolve beneficial knowledge and skills in the long run.
Sustainability Within is a set of Good Growth offerings that focuses on sustainability in the software development lifecycle and as an integral part of development activities. This set of offerings can also be used as an overarching model for making a positive impact through sustainability in the development of digital services.
Tech to save the world (environmental)
We need to ensure that we are working towards environmentally friendly software. We need this to make sure that software can be created, used, maintained, and disposed of with minimal impact on the environment.
We can evaluate this from two perspectives: energy consumption and resource consumption. Resources consumption can include other software products, the software, and hardware configuration of the system, digital obsolescence of both software and hardware, and materials e.g. print paper, storage media. Energy is controlled by its efficiency which includes energy efficiency, runtime efficiency, CPU-intensity, memory usage, peripheral intensity, idleness, and algorithmic efficiency. Furthermore, we should also consider how the energy to run the system is produced as we should choose infrastructure platforms that are carbon neutral or even carbon negative.
Digital resilience (technical)
We need to make sure that the design and operation of long-lived, sustainable systems are not hampered by limited support for the change over time and limited preservation of system knowledge. We need this to make sure that software is being created so that it can easily adapt to future change.
Technical software sustainability is related to the long-time usage of software systems and is referred to as perdurability. Both functional and technical aspects influence software survivability. Functional software evolving is due to requirement changes. Technical evolving is generally due to incessant technology evolution. Quality attributes such as maintainability, portability and usability promote software perdurability.
Services for social capital (social)
We need to create software that enhances social capital values.
We can evaluate this via two aspects: the technical community and the software users. Added social value for the technical community comes from enabling participation, communication, and interaction in the software development process. From software users’ perspective, it comes from added social values for the users, such as, improved information security, ethical use of data, and accessibility.
Developer wellbeing (individual)
We need to be creating software that the developers enjoy working with. We need this to make sure that software is being created and maintained in a way that enables developers to be satisfied with their job over a long period of time.
Evaluating this goes deeper into the software development process and how work is organized. There should at least be a comfortable number of working hours, payment, working conditions, et cetera, and the knowledge and skills needed should be constructive for the developers. In Finland, this is usually a no-brainer, but we should make sure that all people that develop the code are well paid and fairly treated in every part of the production chain.
Business savvy software (economic)
We need to create software that is as safe as possible from an economic risks perspective. We need to be able to make sure that software systems are being created so that the stakeholders’ long-term investments are as safe as possible from economic risks.
We can evaluate the development of economically sustainable software from three perspectives: low costs, long-term profitability, and evolving intellectual capital. The software should have a low-cost process whether looking from market requirements value or physical value with respect to cost aspect. The software should bear a long term profit either from innovation value for market or differential value. Consequently, the software development process should help to evolve the intellectual capital whether looking from a human, structural, or relationship value perspective.
Good Growth offering cards for Sustainability Within
Can we do it together?
Check also my discussion starter “Making positive impact through sustainability in the development of digital services” which plays on the idea if we could incorporate sustainability into our daily software development activities as consultants? Are you getting interested? Do connect and let’s start working together on this. Have you checked what Good Growth is about?
Capability Owner of Web Development