Month: September 2020

Although machine learning security research is still in its early stages, it’s clear that input possibilities without barriers increase threats. You don’t need to touch a keyboard anymore to fool a machine learning system. Software security expert Balázs Kiss touches upon a few points in this new field and gives advice on the basic protection measures.

Just like software in general, machine learning systems are vulnerable. “On the one hand, they’re pretty much like newborn babies that rely entirely on their parents to learn how the world works – including ‘backdoors’ such as fairy tales, or Santa Claus,” says security expert Balázs Kiss from Cydrill, a company specialized in software security. “On the other hand, machine learning systems are like old cats with poor eyesight – when a mouse learns how the cat hunts, it can easily avoid being seen and caught.”

Things don’t look good, according to Kiss. “Machine learning security is becoming a critical topic.” He points out that most software developers and experts in machine learning are unaware of the attack techniques. “Not even those that have been known to the software security community for a long time. Neither do they know about the corresponding best practices. This should change.”

Security expert and experienced software trainer Balázs Kiss recently developed a new course on machine learning security to be rolled out shortly by High Tech Institute in the Netherlands.

Machine learning (ML) solutions – like software systems – are vulnerable in various ways and they increase the security needs. Last year, this was pointed out in a quite embarrassing and simple way by two students from Leuven. They easily managed to mislead Yolo (You Only Look Once), one of the most popular algorithms to detect objects and people. By carrying a cardboard sign with a colorful print of 40 by 40 cm in front of their body, Simen Thys and Wiebe Van Ranst made themselves undetectable as human persons. Another example comes from McAfee researchers who managed to fool the Tesla autopilot by misclassifying speed limit signs and made the car accelerate past 35 mph.

Know your enemy

“An essential cybersecurity prerequisite is: know your enemy,” states Kiss, who is also an experienced software trainer and recently developed a brand new course on ML security to be rolled out shortly by High Tech Institute in the Netherlands. “Most importantly, you have to think with the head of an attacker,” he says.

Let’s take a look at what the attackers are going to target in machine learning. It all starts with exploring what security experts call “the attack surface,” the combination of all the different points in a software environment where an unauthorized user can try to enter or extract data. Keeping the attack surface as small as possible is a basic security measure. Like the students from Leuven proved: to fool an ML system you don’t even have to touch a keyboard.

A common saying in the machine learning world is “garbage in, garbage out.” All algorithms use training data to establish and refine their behavior. Bad data results in unexpected behavior. This is possible due to the model performing well on the training data but unable to generalize the results to other examples (overfitting), the model being unable to capture the underlying trends of the data (underfitting) or due to problems with the dataset. Biased, faulty or ambiguous training data are of course accidental problems, and there are ways to deal with them. For instance, by using appropriate testing and validation datasets. However, an adversary feeding in such bad input intentionally is a completely different scenario for which we also need special protection approaches.

Attackers are smart

Kiss: “We simply must assume that there will be malicious users. These attackers don’t even need to have any particular privileges within the system, but they can provide raw input as training data and see the system’s output, typically the classification value. This already means that they can send purposefully bad or malicious data to trigger inadvertent ML errors.”

“But that’s just the tip of the iceberg,” finds Kiss. “Keep in mind that attackers are always working towards a goal. They will target specific aspects of the ML solution. By choosing the right input, they can actually do a lot of potential damage to the model, the generated prediction and even the various bits of code that process this input. Attackers are smart. They aren’t restricted to sending static inputs – they can learn how the model works and refine their inputs to adapt the attack.”

In case of supervised learning, it encompasses all three major steps of the ML workflow. For training, an attacker may be able to provide input data. For classification, an attacker can provide input data and read the classification result. If the ML system has feedback functionality, an attacker may also be able to give false feedback (“wrong” for a good classification and “correct” for a bad one) to confuse the system.

Crafted inputs

Many attacks make use of so-called adversarial examples. These crafted inputs either exploit the implicit trust an ML system puts in the training data received from the user to damage its security (poisoning) or trick the system into mis-categorizing its input (evasion). No foolproof method exists currently that can automatically detect and filter these examples; even the best solution, where a system is taught to recognize adversarial examples, is limited in scope.

By carrying a cardboard sign with a colorful print of 40 by 40 cm in front of their body, Simen Thys and Wiebe Van Ranst made themselves undetectable as human persons. Credit: KU Leuven/Eavise

There are defenses for detecting or mitigating adversarial examples, of course. However, an intelligent attacker can defeat solutions like obfuscation by producing a set of adversarial examples in an adaptive way. Kiss points to some excellent papers that highlighted these, like those from Nicholas Carlini and his colleagues at Google Brain.

All in all, ML security research is still in its early stages. The current studies mostly focus on image recognition. However, some defense techniques that work well for images may not be effective for text or audio. “That said, there are plenty of things you can still do to protect yourself in practice,” divulges Kiss. “Unfortunately, none will protect you completely from malicious activities. All of them will however add layers of protection, making the attacks harder to carry out.”

Most important, maintains the Cydrill expert, is that you think with the head of an attacker. “You have to train neural networks with adversarial samples to make them explicitly recognize this information as incorrect.” According to Kiss, it’s a good idea to create and use adversarial samples from all currently known attack techniques. A test framework can generate such samples to make the process easier. There are existing security testing tools that can help with this – like ML fuzz testers Tensorfuzzs and Deeptest, which automatically generate invalid or unexpected input.

Sanity checks

Limiting the attacker’s capabilities to send adversarial samples is always a good mitigation technique. One can easily achieve this by simply limiting the rate of inputs accepted from one user. Of course, detecting that the same user is behind a set of inputs might not be easy. “This is the same challenge as in the case of distributed denial-of-service attacks, but the same solutions might work as well.”

As always in software security, input validation can help. It may not be trivial to automatically tell good inputs from bad ones, but it’s definitely worth trying. We can also use machine learning itself to identify anomalous patterns in the input. “In the simplest case, if data received from an untrusted user is consistently closer to the classification boundary than to the average, we can flag the data for manual review, or just omit it.”

Applying regular sanity checks with test data can also help. Running the same test dataset against the model upon each retraining cycle can uncover poisoning attack attempts. Kiss: “Reject on negative impact, Roni, is a typical defense here, detecting if the system’s capability to classify the test dataset degrades after the retraining.”

The most obvious fact about ML security is often overlooked, notes Kiss. “Machine learning solutions are software systems. We program them in Python – or possibly C++ – and thus they potentially carry all common security weaknesses that apply to those languages.” The Cydrill trainer especially advises us to be aware of point 9 from the OWASP Top Ten. The Open Web Application Security Project is a document that summarizes the ten most critical security issues in web applications to raise awareness and help minimize the risk of attacks. Point 9 warns developers about using components with known vulnerabilities. “Any vulnerability in a widespread ML framework such as Tensorflow or one of its many dependencies can have far-reaching consequences for all of the applications that use it.”

Potential attack targets

The attackers interact with the ML system by feeding in data through the attack surface. Start to think with the head of the attacker and ask questions. How does the application digest the information? What kind of data? Does the system accept images, as well as audio and video files? Or are there restrictions? If so, how does it check the types? Does the program do any parsing or does it delegate it entirely to an open-source or commercially available media library? And after preprocessing the data, does the program have any assumptions (empty field, requirements on values)? Is data stored in a relational database or in XML or JSON? If so, what operations does the code perform on this data when it gets processed? Where are the hyperparameters stored, and are they modifiable at runtime? Does the application use third-party libraries, frameworks, middleware or web service APIs as part of the workflow that handles user input? If so, which ones?

Kiss: “Each of these questions can indicate potential attack targets. Each of them can hide vulnerabilities that attackers can exploit to achieve their original goals.”

These vulnerability types are not related to machine learning as much as to the underlying technologies: the programming language itself (probably Python), the deployment environment (mobile, desktop, cloud) and the operating system. But the dangers they pose are just as critical as the adversarial examples – successful exploitation can lead to a full compromise of the ML system. This isn’t restricted to the code of the application itself. Researcher Rock Stevens from the University of Maryland explored vulnerabilities in commonly-used platforms such as Tensorflow and Pytorch.

Real threats

Kiss’ main message is that ML security covers many real threats. It isn’t just a subset of cybersecurity, it shares many traits of software security in general. We should be concerned about malicious samples and adversarial learning but also about all the common software security weaknesses. Machine learning is software after all.

ML security is a new discipline. Research has just begun, we are just starting to understand the threats, the possible weaknesses and the vulnerabilities. Nevertheless, ML experts can learn a lot from software security. The last couple of decades have taught us lots of lessons there.

This article is written by René Raaijmakers, tech editor of Bits&Chips.

As a project manager, system architect and crisis manager in the high-tech industry, Luud Engels has a reputation for not mincing words. In addition to his consultancy work, he recently started as a system architect(ing) trainer at High Tech Institute. “Clear communication is key in complex development environments.”

You don’t want to start with Luud Engels about how open-minded and communicative we are in the Dutch high tech as a system architect. He’ll be forceful in his response, underlining just how hypocritical it is to believe that. “Here in the Brabant region, we’re not that open at all. Just stand at a coffee machine and listen. We’re not talking with you, we’re talking about you.”

When it comes to direct communication – or rather, confrontation – Engels has a reputation. A few months ago, he was sent packing after strongly expressing – according to his client – what was wrong within the company. “I’m convinced that at the right time, you can say anything to anyone – be it in a team meeting or a discussion between two people. Of course, most Dutch don’t do that. But I don’t seem to excel at it either because I sometimes put things so bluntly that people tell me to get lost.”

Engels’ appreciation of factual and clear communication comes from his many years of experience as a project manager, a system architect, a crisis manager and a member of the management team at engineering firm TMC. His advice for development environments: “Speak your mind. Also, about personal stuff. It’s perfectly fine to tell someone his blue shirt bothers you. But statements like ‘Microsoft sucks and Apple is good’ don’t help. Make it factual: are we going to work object-oriented or process-oriented? Are we going to use glass or titanium? What are the advantages? What are the disadvantages? Talking about glass, I don’t need to know the whole history of glassworks. I want the five key criteria – in numbers, not in positives and negatives. If you know the dominant parameters, you also know how to measure them and we can agree on the first development steps to make the measurements possible.”

Engels emphasizes that in the development of high-tech systems, several roads lead to Rome and that it’s important to stick to the choice made. “Make sure the whole team is at least on the same path, rather than endlessly searching for the only right solution – which, by definition, doesn’t exist.”

But sometimes, even the simplest of things can go wrong. “Once, after a positive conversation with a client, I received the report in colloquial Dutch. I asked if the client representatives had approved the text. Of course, they had not. So I insisted on writing it down in English, presenting it to the client and asking them for their approval. After all, it’s often about decisions with far-reaching consequences. Still, syncing with the customer proved a daunting task.”

The laws of Luud

• If the financial people take over, the engineering interest becomes secondary; if the engineers take the lead, it will be financially broken
  (About balancing tech and money in high-tech OEMs)
• The client who asks for a crisis to be averted is half the culprit or part of the crisis in question (About crisis management)
• I firmly believe in the power of the outsider (About the crisis manager)
• We talk past each other: one talks in Newtons per square meter, the other in bits per second (About communication and collaboration in high tech)
• A crisis doesn’t go away by getting rid of the people who put their finger on the sore spots (About stranded development projects)

The outsider

Engels’ extensive technical career started with a study of electrical engineering, after which he joined Sattcontrol, a Swedish industrial automation specialist. He programmed PLCs for egg-grading machines, dairy factories and automated warehouses. Later, he switched to Fortran for PDP and Vax minicomputers.

After five years, Engels moved to Cap Volmac (later Cap Gemini), where he did projects. While he mainly worked in engineering, Cap’s core was business automation. “I learned a great deal about developing computer systems and software according to the rules.”

Engels started for Cap at ASML, he then worked on highway signaling at the Dutch Department of Waterways and Public Works, eventually taking on leadership roles. Later, audits were added to the mix. He estimates that he’s assessed about twenty projects. “After a day of walking around, you know what’s going on and where the project went wrong,” he says. Smilingly: “And certainly not because I’m so smart, or because I saw so much, but mainly because I was an outsider.”

Engels firmly believes in the power of the outsider. “You arrive at companies where things have gone completely wrong and then you’re allowed to walk around and speak to 5-10 people. They all have an opinion about the project in crisis. You get to hear the whole story. People want to pour their hearts out. You hear what’s wrong, and above all: what others aren’t allowed to say.”

The headstrong technician

Technicians are a stubborn, headstrong type – and Engels should know, as he certainly fits that mold. “We’re engineers, aren’t we? We think like this: ‘I’m an electrical engineer and according to my calculations, it’s 5 volts. If you don’t get it, I’ll explain again, but the outcome remains 5 volts. You’re crazy, not me.’ While in projects, it’s mainly about effective collaboration. That’s the difficult part. One talks in newtons per square meter, the other in bits per second. One talks about the goal, the other about the solution. The high tech is one big Tower of Babel. That starts with requirements and continues through to design, integration and testing. Just as well: if I do a project myself and an outsider comes in, he or she will also shoot holes in it.”

Luud Engels will lead the mid-November edition of the System Architect (Sysarch) training in Leuven.(Belgium).

Engels prefers to step in when the crisis is at its deepest. Take the Fusion project that ran at Philips at the end of the nineties. Its ambitious goal was to use a single platform to cover the mechanical, electrical and software construction for medical diagnostic systems. The idea was that cost savings through reuse would justify the extensive operation. “The director outlined his problem as follows: every month, thirty new developers joined the project and every month, they told him that completion was delayed for another two months.”

Engels, again, applied the power of the outsider. “The outsider is allowed to speak up. The deeper the crisis, the more receptive one is to outside messages. Usually, other people have already had a look at it. But often, they put their fingers on sore spots that they weren’t allowed to point to and ended up having to leave. They asked me to replace the current project leader because he couldn’t make up for the delay. But a crisis doesn’t go away when you get rid of the people who put their finger on the sore spots. Instead, I went to help the incumbent project leader. Together, we contained the crisis by adjusting the scope and working with early feedback. One of my laws is: the client who asks for a crisis to be averted is half the culprit or has at least a dominant part in it.”

Is it tunnel vision?

“Please note: you’re talking about very competent people with very relevant arguments and tons of knowledge. But gradually, the solution or working method has been placed in different silos. Very skilled people wear down paths, creating trenches that are so deep that you can barely look over the edge. Everyone has his trench and is defending it stubbornly. You hear people say things like: ‘This isn’t negotiable!’ When you hear that, it points you to where it went wrong and where a possible beginning of the solution lies.”

Where does the solution start?

“The first law of crisis management is containment. With Fusion, it meant that they had to stop adding thirty people per month. Instead, they had to cut twenty a month and reduce scope. The deeper cause – in my opinion – was pure self-overestimation. The platform idea for software alone is a major challenge. But when you start including mechanics and electronics, for all diagnostic products, it becomes too much at once. It’s difficult enough to develop electronics, software and mechanics together for a single system, but trying to develop one platform for different product lines in one project is naive, to say the least. At the time, they also had to work with developers in Bangalore, and they wanted to go from CCM level 2 to level 3 at the same time. That had to stop right away. You need to limit the scope of a project in crisis and postpone long-term improvement initiatives.”

“It’s often the case that the technicians already know what’s wrong and so does management. Both are right, but they won’t reach a solution together. Much later, I did a job at Philips DPS, where I saw that Philips had made significant progress. Putting fingers on sore spots, however, was still not allowed, unfortunately.”

How does this get done the right way?

Start small, says Engels. “You need early feedback, preferably a launching customer. I’ve heard Martin van den Brink say it many times at ASML: put everything together, show me that it works. Then he challenges people by stating: ‘Your physics don’t work.’ There was a lot of that during early integration. Much later, the industry introduced fancy words for it, calling it Scrum, Agile and rapid development. But the point is that you need feedback, and it’s important to start getting it at an early stage. The goal has to be to deliver every six weeks and to deliver something that actually works. If not, you have the means available to find out why it failed, why the physics didn’t work. At that point, you might have to accept that you’re not going to meet your deadline. What you definitely shouldn’t do is bring in more people.”

“When technicians tell you they need more time to investigate something, you have to get suspicious. Van den Brink is also a master at assessing or challenging that.”

Another necessity: “Make people owners of a problem. Certainly in environments with complex developments, where there’s not even a beginning of a solution and new inventions are required, everyone feels like the master of their idea, with their personal insight. We Dutch are also very good at seizing every opportunity to talk about this in a very broad sense. But you simply need to take the next step. That’s the only thing from which a project benefits. So if you’re sitting in a room with thirty people and problems come up, the project manager, the crisis manager or the system architect must assign a person responsible to each problem. This also includes deadlines for results and decisions.”

According to Engels, it’s definitely in the culture of ASML, but there was a point in time when it got out of hand there. “They appointed an owner for everything and called him a project leader. McKinsey once did an analysis at ASML of project leaders and project sizes. They found that, on average, there were 1.2 people on each project, including the project leader! Then you run the risk that these owners, these project leaders, start competing over available resources and the underlying issue disappears into the background.”

Engels has extensive experience as a project manager, system architect and crisis manager in the high-tech industry.

The product manager defines the product that will perform well in the market. He determines the available budget – often too little – and negotiates with the system architect whether it can be made for that money. Engels: “It’s a balancing act. With mature products, it works differently, but with a first development, you want a proof of concept as soon as possible. Or at least a confirmation that your ideas are right and that you’re on the right track.”

To what extent should the system architect, like the product manager, talk directly to customers?

“In high tech, that’s beyond dispute. That’s where the product manager and the system architect come together. They have to. The former has more business focus, the latter looks at the technology and whether it’s feasible. They’re two sides of the same coin. This collaboration between the product manager and system architect is becoming more and more commonplace. However, I still see system architects who downplay the necessary coordination with the project manager or operational management. You then run the risk that a solution that perfectly meets market needs will ultimately fail in the realization phase.”

In smaller development projects, with ten to twenty developers, one person can take on the role of both project manager and system architect. In larger projects, with tens or hundreds of developers and several dozen suppliers, it’s important to split up. Engels has experience in both roles. “The project manager sets hard deadlines and a system architect has to work with them.”

“The project manager must define which issues the system architect still has to solve and with whom. Together, you discuss the ins and outs, weigh the benefits and concerns, decide on key parameters, and then the project manager calls the system architect: at the end of next week, we’ll make a decision! It’s all about direction, coming up with a format that involves knowledgeable people to arrive at quantified statements with which you can really make an assessment.”

A system architect has a major impact on product development, yet often has a less than visible role.

“He’s an experienced technician, but his value lies primarily in his view of the business. Ninety-nine times out of a hundred, the system architect knows the market in which his product or system is going to land. This is necessary to translate the market and product requirements into the system requirements and then outline the design.”

It takes quite a bit of experience to reach that level. At the same time, Engels observes that the concept of a system architect is subject to inflation. “Nowadays, there are architects all over the place. A software architect is usually a senior software developer, a requirements engineer or someone in charge of engineering. I wouldn’t say anything to the detriment of such a lead engineer. Still, the difference with the system architect is that the latter has to know the business, understand how value is generated and thus understand why it has to be done within a certain amount of time and money.”

“This is also the case in construction. Your architect asks you what you are going to do with your future house and adapts his design accordingly. Are you going to cook a lot, or do you mainly want to drink wine? That’s why Van den Brink does so well at ASML. He goes to customers and explains what kind of litho systems they need. He knows the market like no other. Even stronger, he dictates the market. That means he understands the goals and the timing of chip manufacturers like no other, including what their production processes look like. If they talk about critical dimension and overlay, he can explain that his machine can do that and also substantiate why.”

This article is written by René Raaijmakers, tech editor of Bits&Chips.

With the growing reliance on software in an increasingly high-tech world, it’s more important than ever to master the art of software engineering as software architects. Trainers Robert Deckers and Bart Vanderbeke have taken it upon themselves to turn developers into craftsmen.

“A colleague once told me about one of his former project managers, who, upon realizing that the estimates didn’t align with his timeline, just cut them in half to make them fit. I find it unheard of, not only that you’d do such a thing as a project manager but also that people stand for that kind of behavior. You don’t have to scold him, but you can open your mouth. Instead, at the end of the project, when everything has gone haywire, everyone complains about how this has happened to them.”

Inspired by Google executive Fred Kofman and his book “Conscious business,” Bart Vanderbeke calls on software architects to stop playing the victim. “It’s unacceptable and unhealthy,” he claims. “You’re the craftsman. When someone tells you that you need to do something in half the time, or skip the design, or refrain from reviews, you say no – constructively. Software architects are scarce, so you’re in a comfortable position, certainly no position to self-victimize. Don’t hide behind ‘management.’ As a software craftsman, using a term coined by Kofman, you’re ‘unconditionally responsible’ for everything you do or don’t do.”

“You need to take unconditional responsibility, which literally means that you need to have the ability to respond – in a meaningful way,” says Bart Vanderbeke. Credit: Bart Vanderbeke

At NXP in Leuven, Vanderbeke leads a team of fifteen software architects, working on 2.4 GHz radio applications for personal health – think hearing aids, headphones and earplugs. “Tiny systems containing tiny software stacks,” he notes. “But even if you have a codebase of 100k or 200k, like us, software craftsmanship is of paramount importance. Building the hardware takes about a year, followed by maybe five years of software enhancement. I’ve developed a series of lectures to help my colleagues bring out their inner craftsman.”

The non-functional

A kindred spirit, Robert Deckers, too, aims to increase software craftsmanship, but with a focus on software architecture – “the most difficult trick of the trade,” as he calls it. “It already starts with the question: what is software architecture? You can find hundreds of books that try to give an answer. While some are bad, terrible even, most of them are meaningful, but they all tell a different story.” This was one of two triggers that led him to dive into the subject, develop his own view, write his own book and bestow his insights upon others.

The second trigger was the realization that in traditional methodologies, there’s too much focus on the functional requirements, whereas the non-functionals are the hardest to get to grips with and therefore take up the most time. “Way back when I was an OOTI trainee at Eindhoven University of Technology, I was the software architect for a copier,” reminisces Deckers. “After two months of design, the anomalous system behavior started to rear its ugly head and I realized that we had to do error handling as well – while obvious to someone with 20 years of experience, it hadn’t crossed my newbie mind. When we were finished, to my big surprise, no less than 85 percent of all our code turned out to be for error handling, so only 15 percent of our efforts had been focused on the functionality. That’s when I first experienced that the real challenge, the real complexity, is in the non-functional.”

After the OOTI traineeship – the PDEng Software Technology, as it’s known today – Deckers sharpened his views at several companies, including Philips Research and Sogeti. Since 2013, he’s running Atom Free IT, coaching organizations and their architects, helping them create architectures, set up the architecture process and embed it. The last five years, he’s combining this with a PhD project at the Vrije Universiteit Amsterdam, researching the cognitive aspects of systems engineering.

Come prepared

Vanderbeke and Deckers are the newest additions to the software and systems portfolio of High Tech Institute. Both want to help software architects be better at their work – become real craftsmen. “As a software craftsman, you know how to organize your work and you have the assertiveness not to accept compromises on the way of working. Instead, you go for the optimum, taking into account the influencing variables and conditions. You don’t do things because someone tells you to, but as you understand the need, you autonomously decide to do so,” summarizes Vanderbeke the values he intends to convey in his workshops.

Robert Deckers stresses the importance of focusing on the non-functional properties, aka the quality attributes.

Learning to say no in a constructive way is a key topic in Vanderbeke’s teachings. “That requires you to come prepared. When you’re asked to plot a course in a project, you need to have a couple of options readily available, not down to the minute detail but to such an extent that you can weigh them and make an informed choice. When someone steps up to you and says something can be done in half the time you estimated and you don’t have your facts straight, he may well be right – you have no way of telling. If you know what you’re talking about, that will not happen. You can have a constructive conversation and you might be challenged, persuaded even, but you won’t let yourself be blown away by unsubstantiated claims. Someone once asked me if we could speed things up by taking shortcuts, upon which I replied: ‘The only shortcut you can take is skimp on the specs’ – and that was the end of the discussion.”

“You need to take unconditional responsibility, which means that you need to have the ability to respond – in a meaningful way,” continues Vanderbeke. “In my workshops, I use several small examples, taken from my everyday work, to get my point across. For instance, someone escaping responsibility would say: ‘I cut my estimation in half because my project manager told me to,’ as opposed to someone keeping ownership, a ‘player’ in Fred Kofman’s terms, who would say: ‘I wanted to avoid a fight with my project manager, so I gave in.’ Likewise, a victim would say: ‘I make estimations because our process demands it,’ whereas a player would say: ‘I want to stay with the company, so I use the established process.’ By making them aware of these little things, people are more inclined to correct their behavior.”

A good architecture is correct, consistent and communicated. Credit: Robert Deckers

Fish nor fowl

In his training courses, Deckers relays his ideas about good architectures. “The role of architecture is to offer a solution approach for the key system properties that are the hardest to realize. As a system architect, you always have to make sure you’re working towards a solution, providing guidance and serving your stakeholders’ needs, while also keeping an eye out for things that could go wrong if not addressed in the architecture. If you’re not doing this, you’re probably not architecting. Also, I want software architects to understand that an architecture needs to offer business value and that it’s feasible to build the system within the organization at hand. You can only be an effective architect when you’re prepared to step out of your technology comfort zone.”

According to Deckers, a good architecture is correct, consistent and communicated. “A system has to be correct in that it has to adhere to the stakeholder concerns and the technical environment. The development process has to be consistent. At Philips in Bruges, I once witnessed a software architect testing all preconditions of all the functions he programmed because he wanted his code to be robust. Meanwhile, in the cubicle right next to his, a colleague was using pointers without testing anything because he wanted his code to be fast. Combined in one system, that gives you neither fish nor fowl. You need to be clear on the key properties – my advice: hang the top five on the wall. Finally, an architecture should be described in such a way that you can discuss it with the different stakeholders, which means using different views for different aspects.”

Deckers stresses the importance of focusing on the non-functional properties, aka the quality attributes. He acknowledges that this seems to be at odds with the popular Agile principle of delivering working software as quickly as possible. “People often ask me: how do you match Agile and architecture? My answer to them: you don’t. They’re two different mindsets. Architecture is about looking before you leap, whereas with Agile, you just go and adjust based on the feedback you get. That’s perfectly fine for some businesses, but not for a copier or a medical scanner, where aspects like reliability and safety are known beforehand. The closest way to match Agile and architecture is to bend the rules and dedicate the first few sprints to the key concerns.”

Descending down the management funnel, the focus narrows and the risk for conflict grows.

Better decisions

With collaboration, there’s bound to be friction. A software craftsman, therefore, also needs tools for conflict resolution. In his workshops, Vanderbeke presents a management funnel doubling as an inverse conflict pyramid. It goes from wide to narrow in three levels: strategic, tactical and operational – from the what to the how. Descending down the funnel, the focus narrows and the risk for conflict grows. When a conflict actually arises, going back up the funnel to try and find a shared goal or principle helps to smooth things over.

“Software architects who are in disagreement about the way to tackle a problem often are at the bottom, stuck in their own solution. Taking them up and discussing the problem criteria usually ends the stalemate as they establish common ground,” illustrates Vanderbeke. “It’s a very useful instrument in process management as well. When you’re in a meeting that’s going nowhere, revisit the reasons why it was set up in the first place and a way out will present itself almost automatically.”

Stocked toolbox in hand, software engineers are well equipped for craftsmanship. With Deckers, Vanderbeke concludes: “It would be great to see them make better decisions. To see them operate more autonomously. And, at the same time, to see them have more fun in what they do.”

This article is written by Nieke Roos, tech editor of Bits&Chips.