Month: October 2019

Article originally posted on InfoQ. Visit InfoQ

Mark Schwartz is speaking at the 2019 DevOps Enterpise Summit in Vegas. He gave us an interview about his presentation and his new upcoming book about bureaucracy. 

InfoQ: Thank you Mark for answering few questions for our readers. Could you tell us what you do at Amazon?

Mark Schwartz: At Amazon, I’m called an enterprise strategist, which means that I’m part of a small team of people who were senior IT leaders before joining AWS and who made the journey to the cloud and digital transformation. We help our customers in part by meeting with executives of large enterprises and to solve some of the impediments to transformation, impediments that are usually not technical. We help them address things like cultural change, organizational structure, financing models for IT investments, coping with bureaucracy, and getting their employees the right skills to make these transformations. We learn from our customers what their impediments are, and we find that the same questions come up very consistently. I talk to over a hundred enterprise leaders each year and speak at conferences. I also write books and articles about what we’ve learned from our customers about what their hurdles are. Our role is purely to help them in their transformation journeys.

A transformation can be a very difficult journey for an enterprise. Moving to the cloud itself is very straightforward and the same can be said about DevOps. You can learn to do DevOps, and it’s a route that others have gone through. The challenge for large enterprise is actually getting the business value out of it. Actually, doing DevOps is not difficult, but to really get the full power of it, you need to make changes in how you structure your organization, how to make the work flow through your organization, and how to make investment decisions – what IT initiatives to fund.

One of the goals of DevOps is to deliver value very quickly, using very short lead times. But if you think about it, the time from when you decide to do something to the time when you finish the product and deploy it, most of that time is not the part that DevOps covers. DevOps is primarily about the time from when code is completed to deployment. But the process of going from an idea to a deployed capability is much longer and touches on a lot of other things. In particular it includes a lot of things before development starts. It includes collecting requirements, building the business case, justifying the business case, and the governance process, which takes most of the time. And if you don’t address that, then we are not getting all the value out of DevOps.

This is what I work on – how can you structure your organization for short lead times, and how we can rethink the processes of overseeing an investment, because in the old ways, you write a lot of requirements, you make a project timeline, you check progress against that timeline – and if you’re going to do that, it’s going to take a lot of time. Your lead time is going to be longer. But there are better ways that drive results and value quickly, and that give you even more control over your investment.

InfoQ: Your presentation is titled “Eating a bureaucracy one bit at a time with DevOps”. Can you tell us a little bit more your talk and your upcoming book?

Mark Schwartz: The book doesn’t have a title yet and I’m in the middle of writing it. But the subject is bureaucracy, so it’s the same subject as my talk and I’m using the talk as a way to try out some of the ideas – to think it through iteratively. Bureaucracy is something I became very interested in when I was working in the government. I realized that there’s a lot more to bureaucracy than most people think. Most people use the word bureaucracy for anything that gets in their way, it’s like a generic word to describe their challenges and hurdles along the way and what I found is that bureaucracy is put in place for a reason, although there are ways to accomplish what it’s intended to do that are much better. Many times, our IT organizations, even though they dread bureaucracy, contribute to creating it through standardization and through processes they put in place to solve problems as they find them. So, I think it’s possible to take bureaucracy, which is typically such a terrible impediment, and find ways to make your bureaucracy leaner, by eliminating waste, and unnecessary steps.

A second issue with bureaucracy is that it doesn’t change fast enough, so we need to make our bureaucracies learn, to make them change and adapt to change faster. Usually bureaucratic rules tend to stay for a long time, but there is no reason why that has to be. You can make bureaucracy learn through fast feedback cycles and continuous improvement. The essence of bureaucracy is that the rules are applied strictly to everything and there are no variations from the rules. But that doesn’t say anything about how the rules are created in the first place and they can easily be created through a learning cycle where the rules are constantly changing. My presentation is going to walk people though a sort of personal journey of my battle against bureaucracy during my time working with government agencies, and the steps we successfully took to overcome the obstacles it presented.

If you do those two things – make the bureaucracy lean and learning – then bureaucracy becomes one of many different ways you can establish control over process. We’ve already done this in the DevOps world for example, where we automate a lot of bureaucracy. For example, a lot of the compliance controls and things that would normally be bureaucratic constraints, we automate them to enforce them. Note that we’re still enforcing bureaucratic rules, but we do it in an automated way which makes it much leaner. We take waste out of the process, we increase velocity and throughput. So, I think bureaucracy can be made lean and that’s the first important thing to do.

I am developing a playbook that describes the series of steps you can take to cope with bureaucracy. It is true for both governmental organizations and for commercial enterprise. It’s really similar in so many ways and it’s interesting to compare the two and see how bureaucracy works in both environments, what the differences are.

InfoQ: How do you approach bureaucracy? Do you approach it one team or VP’s org at a time, and then you scale what can be scaled, and descale what needs to be descaled, or do you tackle it from the top?

Mark Schwartz: I didn’t coin this term, but I love it: “Provoking and observing”. I think that’s the technique that works. As you’re trying to move forward with the transformation you try something with the intent of finding out where the obstacles are. So, you provoke, and you observe what happens. That will tell you where bureaucracy is, where and what are the hurdles getting in people’s way. And then you devise the strategy for getting around that problem and then you provoke again in a different way and you just keep doing that because that’s how you learn where the bureaucracy doesn’t fit the process very well, which informs what you need to do.

InfoQ: In this effort, do you need the commitment of executives?

Mark Schwartz: Yes, you need the commitment of people high in the organization, but I think people make the mistake of thinking that you have to have that commitment before you can act, and that’s always a mistake. Instead, you can start acting right now and then you learn what you need to convince the CEO and leadership with the results you have delivered. It becomes a matter of influence or selling ideas, which is also part of the transformation. You can do a proof of concept, for example, and use it to eventually get the CEO and leadership’s commitment, but you don’t need that to start.

InfoQ: We often talk about the role of the CIO, but not enough about the CEO or their partnership in transformations and why it’s so critical for them to partner. I think that as we are looking at the structure of our organizations and at influencing so many important changes that need to be concurrent in order to be successful, and not siloed, such as enterprise Cloud and DevOps, Agile, business innovation, product organizations, and culture across all of that, I think the CEO and CIO need to partner even more closer than never before.

Mark Schwartz: That’s what my last book, War and Peace and IT, is about. The worst silo problem that organizations have is that separation between something called the “business” and something that we call IT. These two are the most damaging silos because it means that the business has to write requirements and toss them over the wall to IT. Most of the process that creates is a waste. A lot of that process doesn’t need to be there if you get rid of those two silos, business on IT. There is just one business and IT is part of it, not a separate silo. So, the picture I touch on in War and Peace is what it could look like if the business and IT are actually the same thing, a single unit together. So, when you talk about the CEO or the CIOS working together, that’s what I think will happen. Actually, what’s happening is that the CEO’s organization is creating goals for the business, and everybody – business and IT – is just working together towards those goals. That’s the way I see it. We have to confront a lot of bureaucracy but it’s possible.

InfoQ: Who is your new book intended for?

Mark Schwartz: As with my previous books, there’s a sweet spot for my writing that includes non-IT executives and senior IT leaders. But I think that so many people are frustrated with the bureaucracy they face, that it will have something for everybody, perhaps software developers in particular. Everyone seems to have a different definition of bureaucracy. And it matters because if you understand what the bureaucracy consists of you can figure out how to get beyond it, how to nudge it out of your way. So, the book will help about anybody in organizations that cope with bureaucracy. When I talk about these ideas to leaders of the companies I meet, they are all enthusiastic about having a book to address these common challenges.

InfoQ: When will it come out?

Mark Schwartz: The book is in its infancy phase. I plan to finish writing it early in 2020, but the publication process can take a while. I’ll let you know as release gets closer!

Article originally posted on InfoQ. Visit InfoQ

Matthew Gerstman, Senior Software Engineer at Dropbox, recently presented at ReactiveConf 2019 in Prague the lessons learnt by Dropbox after Dropbox migrated to TypeScript four years ago. Gerstman described good, bad and ugly parts of TypeScript, and how TypeScript helped Dropbox to tackle programming at scale.

Gertsman started with giving the audience a practical definition of types, as an attribute of data that tells the computer how the programmer intends to use it. Basic preexisting TypeScript types (like Boolean, String or null) can be combined to form other types, with the any type being an escape hatch encompassing the type of every possible value. In a standard TypeScript codebase, programmers typically annotate code with the relevant type information. Through type inference, TypeScript is then able to detect occurences of type mismatch and inform the user of incoherences at compile time.

Gerstman illustrated with live examples how the IDE leverages TypeScript to support type error reporting while editing code. With proper typing, the IDE understands the shape of the props expected by a React component and is able to complain instantly about missing props when calling that component, in all relevant call sites. IDE may also leverage third-party libraries’ TypeScript definitions to enable automatic completion for developers.

The increased developer convenience comes at a price. Types can be complex enough to be difficult to grasp, specially for developers who are just starting to use TypeScript. As a matter of fact, the filter method from the popular lodash utility library has 14 different type definitions, most of which are derived from other (possibly derived) types with also a significant number of overloaded type definitions. Gerstman additionally explained that testing require very well mocked data or lots of anys. Furthermore, because advanced JavaScript translates to advanced TypeScript, some functional patterns like higher-order functions , according to Gerstman, are really hard to type: developers need to know about generics, intersection types, and discriminated unions. It may even be that some functions may not be typed accurately enough to guarantee type safety.

This results in Gerstman warning developers:

TypeScript is going to get in your way for the first few months.

Continuing on the list of potential issues with TypeScript, Gerstman mentioned that TypeScript is not sound, as it may allow some operations whose safety cannot be guaranteed at compile time. Some of this is by design, to strike a balance between correctness and productivity. Another part comes from the fact that a typical codebase may import foreign codebases, which may be inadequately typed (for instance with substantial use of any). Sebastian McKenzie, creator of the Babel JavaScript compiler and the Yarn package manager, testified on Twitter:

Local variable refinements are unsafe in TS and Flow. Both are bad, TS is the worst. Seems obvious in hindsight but neither handle local refinement invalidation correctly. I’m not speaking abstractly, this has caused bugs in my code before.

As part of the list of abstractions which are difficult to thoroughly type with TypeScript and that are used commonly by front-end developers, Gerstman quoted React Context, React Redux (implemented with React Context), Redux Thunk or dispatch. In such cases, developers will often have to help the TypeScript type system to infer the correct types by inserting type annotations.

In spite of the aforementioned issues, Gerstman nevertheless contended:

All of this is worth it.

TypeScript eliminates classes of bugs, among which the undefined is not an object and variable is not a function classes. Gerstman explained that at Dropbox scale, with hundreds of engineers across four time zones working on the same codebase, hundreds of features, and millions of lines of code, TypeScript provided hard-to-replicate benefits, and became a core part of Dropbox front-end workflow. Gerstman mentioned:

At our scale, I don’t know how we would upgrade libraries without TypeScript.

Gerstman then provided practical examples of TypeScript benefits at Dropbox. In Dropbox’s experience, TypeScript catches the vast majority of breakage when upgrading a library. TypeScript allows Dropbox to place constraint on engineers, such as preventing usage of some methods in a library. Dropbox as a matter of fact temporarily prevented usage of Hooks, or restricted lodash usage.

Gerstman added that while TypeScript does not provide free documentation, nor free tests, it does provide contract validation across the stack, from the back-end all the way to the component library. Developers may use for APIs GraphQL, Swagger, or Dropbox’s Stone and autogenerate backend types in TypeScript. Changes in APIs thus are immediately propagated to the front-end, and a possible breakage is detected ahead of time. Conversely, when the front-end team updates the component library, TypeScript types also allow to detect the impacted piece of codes and correct immediately possible misalignment occurring in other places.

Gertsman warned however that with TypeScript developers still need to write tests, perform code reviews, and think about architecture. Still, TypeScript allows developers to forget about other parts of the codebase which are impacted by a change, and that is according to Gertsman a key advantage for maintainability. As he explained:

The metric for success in a codebase is how few things you need to keep in your head at a time.

Gertsman limited the cost of TypeScript to the learning of it, which may take time, and feel painful in the beginning, and concluded by arguing that that cost is not so expensive vs. the benefits derived from an easier refactoring and better code maintainability, specially in large codebases.

ReactiveConf is a yearly conference targeted at developers with talks addressing the latest technologies and trends in software development. ReactiveConf 2019 took place from Oct. 30 until Nov. 1, 2019, and is the fifth installment of ReactiveConf.

Article originally posted on InfoQ. Visit InfoQ

With the release of iOS 13, Apple now includes native iOS W3C WebDriver support. Beyond previous support for WebDriver added in Safari 10, WebDriver can now easily be used for testing mobile Safari web applications efficiently.

While it was previously possible to use WebDriver with iOS Safari via the iOS simulator or various cloud-based testing providers, the native WebDriver support provides additional testing features as well as a better mobile UI testing experience.

The native WebDriver API provides safeguards against malicious code as well as flaky tests. The Safari WebDriver implementation restricts browsing in WebDriver sessions. Tests get isolated within a separate set of windows, tabs, preferences, and persistent storage, existing tabs get hidden, and a distinctively-colored WebDriver window gets shown with an orange Smart Search field. This approach helps both with security and privacy, as well as ensuring that tests do not get influenced by previous sessions. Upon test completion, any local state such as cookies get deleted.

To prevent unintended user interaction during automated test sessions, Safari adds a pane over the automation browser window, blocking any interactions. If a running test gets stuck or fails, the developer can tap on the screen and choose to end the WebDriver session. WebDriver-initiated navigations cannot be handled outside of Safari. For example, clicking an app store link will not redirect to the App Store.

To begin working with the WebDriver support on macOS devices running Safari 13 or newer versions, developers need to run safaridriver --enable and authenticate as an administrator. Then on the iOS devices for testing, developers need to enable Remote Automation (Settings → Safari → Advanced → Remote Automation). Developers then need to plug in their iOS device into the macOS host, trust the host, and unlock the iOS device when starting a WebDriver session.

The WebDriver configuration should include ‘platformName’: ‘ios’; to differentiate between running iOS simulator or the native macOS test. To use the iOS simulator for testing, add the capability 'safari:useSimulator': true.

WebDriver for iOS is available with iOS 13 and newer versions and requires a macOS host running Safari 13 or later.

Article originally posted on InfoQ. Visit InfoQ

Dr Rashina Hoda, Senior Lecturer in Software Engineering in the Electrical, Computer and Software Engineering department at the University of Auckland, New Zealand, gave a TEDx talk titled Agile Nation: New Zealand’s response to terrorism in which she reflected on the country’s response to the terror attacks of 15 March 2019 and how that response portrayed the traits of agility at the national level, and how this could be an example for the rest of the world in adopting humanistic policies and becoming agile societies to tackle global challenges.

She started by explaining the background to agile development as an approach that provides guidelines for coming to a better solution faster. She related the 20+ year history of agile development in software and how the ideas are expanding beyond software development into broader business areas.

She then recalled the mosque shooting that occurred in Christchurch, New Zealand, on March 15, 2019 in which 51 people were killed. She said that the government and society response was an example of the values of agility at a truly national scale. She explained her own perspective as a Kiwi, Indian, Muslim woman and how she felt in the aftermath of the event and how the response from people arround her and in society at large was overwhelmingly supportive and caring.

She reflected on the VUCA nature of the world and how businesses have applied agile thinking to responding to the VUCA nature of the business ecosystem, arguing that this was the first time that New Zealand society had truly experienced the true impact of many global trends.

She described the elements of VUCA as

• Volatile messages and violent weapons
• Uncertain and unethical technologies
• Complex and fake news
• Ambiguous laws and protocols

Her own research into teams and organisations adopting agile approaches has shown that in order to gain the benefits of the approach and to thrive in the VUCA business world businesses need to bring agile attitudes and thinking from the top down and from the bottom up simultaneously. She then reflected on what that means for a society as a whole and explained how the New Zealand government and people exhibited agility in the responses to the events of March 15.

She presented her view of the manifesto for agile development restated for an agile society.

The four values for an agile society:

• People & interactions over protocols and rules
• Community collaboration over closed decision making
• Policies and actions over speeches and promises
• Responding to change over following the status quo

She gave moving examples of how at the individual, community and government level New Zealanders exhibited these values in action.

She explained how New Zealand society and government exemplified the characteristics of agile organisations (self organising and cross functional with empowering leaders) and agile leadership (human-centric and inclusive) in response to the attacks – an exemplar agile nation in the face of one of our darkest days. 

She ended with a call for action – for everyone in the world to apply agile values at the personal and systemic level in order to become agile nations and societies.

When tribes and leadership respond swiftly and with conviction we can see change. People around the world can self-organise around the biggest challenges facing our planet today:

• Terrorism and hate-crimes against all communities
• Climate change
• Poverty
• Inequality 

InfoQ spoke to Dr Hoda and asked her if there are any specific lessons that the software industry should take from the shooting and its aftermath: 

Using agile values to deliver better software faster is great. But the need of the hour is to embed core human values into the software we design and in how we can use it.  Agile to me is all about people. Software designed by and for people should ultimately benefit society and it should not be easy to misuse it to harm people. Much like the medical profession, the software engineering profession needs to have a strict code of ethics and a clear focus on human values across the full spectrum of its core activities. Educational institutions have a large role to play in this, as do multinational software firms

The spread of hate speach and radicalism using software tools is one of the factors in the discussions around ethics in software engineering, as evidenced by some recent InfoQ articles:

• The ACM Code of Ethics and Professional Conduct which talks about the obligation on computing professionals to contribute to human wellbeing and avoid harm. 
• There is discussion about the need for the power granted to software professionals  to be grounded on an ethical code of conduct.  
• Large players in the AI space are actively starting to tackle some of the real harm that has been done through fake news through initiatives such as the Deepfake Detection Challenge. 

Article originally posted on InfoQ. Visit InfoQ

The 2019 Accelerate State of DevOps presents the capabilities and practices that contribute to software development and organizational performance. This year, DevOps has crossed the chiasm. While a well implemented cloud computing strategy helps deliver superior results contributing to speed, stability, and availability.

By Shaaron A Alvares, Nicole Forsgren

NoSQL Market presents a detailed competitive outlook and systematic framework of nosql market at a global uniform platform. The report commences …

Article originally posted on InfoQ. Visit InfoQ

In a recent post, Spotify engineer Patrick Balestra explained how they managed to improve Xcode build time by 50% using dependency manager Carthage to avoid rebuilding dependencies over and over across their teams.

When using Xcode, you have different options to handle external dependencies. You can do it manually or you can use a dependency manager such as CocoaPods, Carthage, or the Swift Package Manager. With the exception of Carthage, Xcode dependency managers usually rely on building all external dependencies from source, while Carthage supports downloading an already built binary from GitHub or getting it from a known local location.

Building dependencies from source has huge implications on productivity, says Balestra, since all developers will have to build external dependencies on their machines as well as each time they clean your project artifacts, e.g., when starting a new continuous integration build. From the analysis of their build logs, Spotify engineers came to a striking conclusion.

Comparing the time spent building the Swift source code of the Spotify for Artists app with its dependencies in our continuous integration environment, we quickly realized that around 60-70% of the time was spent compiling the same dependencies over and over again before we could actually build our own code.

This state of things could likely change now that Swift has got support for framework binary stability and the Swift Package Manager could at some point introduce support for binary distribution of frameworks too. But for the time being, the only available option to manage binary dependencies in Xcode is either manually or through Carthage.

The advantage of linking pre-built binary modules is even greater if they are shared across the team and the CI pipeline, which requires using some kind of distributed storage. In such case, team members and the CI pipeline can directly link the shared binary modules. Since Carthage only supports local storage of binary modules, developers usually use a third-party tool like Rome to cache Carthage artifacts to an S3 location where they are available to the whole team.

Rome speeds up future builds by removing the need to rebuild the same dependencies. This is achieved by caching the contents of the Carthage/Build directory to an external local folder (e.g: ~/Library/Caches) or a remote server (e.g: Amazon S3).

Since at Spotify engineers do not use S3 and rely on Artifactory, they had to extend Rome so it supported additional remote storage systems. Thanks to their work, you can now use a script written in your preferred scripting language to enable Rome to store remotely your Carthage artifacts wherever you want. This brought a significant improvement.

After merging support for Rome, it didn’t take long to notice an improvement. We saw an immediate reduction of around 50% in the time taken in our CI configurations that build the Spotify for Artists app: from around 20 minutes to under 10 minutes!

One major issue Spotify engineers discovered is the inability of LLDB to debug into cached binary modules, since the compiler stores absolute paths for the symbols found in the binary. This behaviour should have changed in the latest Xcode version supporting Swift 5.1 and binary module distribution, but InfoQ has been unable to confirm with Spotify which Xcode version they were using. We will update this post as soon as we get an update from Spotify.

Article originally posted on InfoQ. Visit InfoQ

Researchers from Microsoft and the University of Maryland (UMD) announced Free Large-Batch (FreeLB), a new adversarial training technique for deep-learning natural-language processing (NLP) systems that improves accuracy, increasing RoBERTa’s scores on the General Language Understanding Evaluation (GLUE) benchmark and achieving the highest score on AI2 Reasoning Challenge (ARC) benchmark.

The team, drawn from Microsoft’s Language and Information Technologies group and Professor Tom Goldstein’s lab at UMD, provided a detailed description of FreeLB in a paper published on arXiv. The method works by adding noise to the word embeddings of input sentences when fine-tuning a pre-trained model such as RoBERTa. FreeLB builds on previous work done by Goldstein’s lab, in which adversarial training is performed “for free” by re-using the gradient information that is a result of standard training algorithms; the gradient is used to calculate a perturbation that is added to the input samples to create adversarial inputs. By including these samples in the fine-tuning training, the team was able to improve a BERT-based model’s score from 78.3% to 79.4%, and a RoBERTa-large model from 88.5% to 88.8% on GLUE. The FreeLB training also took the top spot on the ARC leaderboard with 85.44% and 67.75% on ARC-Easy and ARC-Challenge respectively.

Adversarial training for image classifiers has been a focus for many researchers, especially those interested in autonomous vehicles. The FreeLB team notes that while this improves the robustness of the models, it often reduces their accuracy. However, NLP systems usually see an improved accuracy with adversarial training. There are several techniques for generating adversarial inputs to NLP systems by manipulating the input text: for example, by adding distracting sentences, or even by changing single words or characters (a technique that can also be used to help explain a model’s output).

By contrast, FreeLB does not directly manipulate the input text. Instead, it adds a perturbation to the embedding vectors used to encode the input. Embeddings, frequently used as the first step in an NLP system, convert each word in the input vocabulary into a high-dimensional vector that often has interesting properties on its own. For example, words with similar meanings are often “close” to each other in embedding space. FreeLB uses the gradient information from training to adjust the location of words in the embedding space with the maximum distance possible, without changing the output generated by the model. The authors claim this is even more effective than modifying text directly, as it can “make manipulations on word embeddings that are not possible in the text domain.” The perturbations are done during fine-tuning when a pre-trained model is further trained on a task-specific dataset, such as a set of questions and answers. Because this training process calculates gradients, they are available “for free” to compute perturbations, which effectively creates new training examples.

FreeLB’s implementation has not been open-sourced, although other projects from the Goldstein group’s have been, including the previous work on adversarial training of images which is available on GitHub. The team notes that:

Investigating the reason for the discrepancy between the outcomes of adversarial training for images and text is an interesting future direction.

The Microsoft team has also open-source some of its other work, including a recently-released system for visual question answering called ReGAT, also available on GitHub.
 

Article originally posted on InfoQ. Visit InfoQ

The Swift Method is a set of techniques for analyzing complex, legacy systems, and determining the work required to gradually modernize key components or the whole system. Shaun Anderson, principal solutions architect at Pivotal Software, introduced the Swift Method to attendees at Explore DDD 2019, and gave examples of how the five tools and techniques have been used to successfully update enormous (up to 5 million lines of code), mission-critical software systems.

Anderson believes asking the question “What is modernization?” has very different answers depending on who you ask. Technical leaders focus on the “how,” defining a modern system in terms of tools and technologies, like Kafka and containers. Conversely, business stakeholders look at “why” modernization is important, looking at business results, pain points, and costs. The Swift Method considers both these viewpoints, using exercises that incorporate both non-technical, top-down and technical, bottom-up analysis.

When working with clients, Anderson concluded that having a global definition of modernization wasn’t important; a team needs to define what it means for them. This requires good communication and shared understanding of the system and the challenges. For the Swift Method, Event Storming is used to make sense of the chaos and complexity of legacy software and the associated business processes by discovering clumps of business events that are likely service candidates.

The notional service candidates are the starting point for the Boris Exercise, which uses graph theory to determine the way “the system wants to behave.” Similar to Event Storming, Boris uses a lot of sticky notes, one for each domain, node, or service, placed on large butcher paper. Whiteboard tape is used to connect the sticky notes to indicate communication paths between nodes, thereby creating a visual map of the system. At first, the Boris Exercise should be used to find the notional architecture, by following the “happy path” and thinking about thin slices through the system from a process perspective. Later iterations can be used to walk through special cases, as the 80% case provides the desired clarity without getting too cluttered. 

The results of the Boris Exercise are captured using a rapid documentation technique called SNAP-E. For each service, the corresponding SNAP-E consists of documentation about five categories: APIs, Data, External Systems/UI, Stories and Risks. The goal is to capture the information, and avoid analysis paralysis.

After the analysis and documentation has been completed, the fourth step is to start identifying technical patterns that can be used. By again thinking about “how the system wants to be designed” and working towards modernization, this often includes anti-corruption layers for monolith decomposition, CQRS and data storage patterns, asynchronous messaging, and/or microservices.

The final step in the Swift Method is to create a backlog of the work to be done. The knowledge captured in the SNAP-Es is combined with the desired technical patterns, to create a set of stories, and then prioritize them.

To avoid over-analyzing the problem, the team should pause the Swift Method once they are able to create a prioritized backlog. As modernization work begins, the team can periodically re-visit the process to work on subsequent phases.

The Swift Method is also useful for greenfield applications. Those familiar with DDD will recognize the goals of identifying a core domain, breaking down a complex system into bounded contexts, and using a ubiquitous language to improve communication and collaboration.

Anderson said the Swift Method came about partially due to “constructive laziness.” When he was brought in to help modernize a mainframe system, the sheer size of the codebase meant trying to learn about a legacy system by reading the code was impractical. Event Storming got everyone in the room to also avoid focusing on the code, and think about the big picture. 

After the conference, InfoQ sat down with Anderson.

InfoQ: How long have you been using the Swift Method?

Shaun Anderson: It started about three years ago. Since then, we’ve used it successfully with several Fortune 500 companies.

InfoQ: Were all those customers trying to modernize mainframe systems?

Anderson: No. Some were mainframes with a lot of COBOL. Others were large J2EE or WebSphere systems. We’ve also used it for greenfield scenarios. The entire process is programming language agnostic.

InfoQ: What guidance do you have for someone trying to facilitate a Swift session?

Anderson: Sometimes the facilitator will see the solution faster than other people in the room. It’s very important to let the team get there on their own. This creates a better sense of ownership of the solution, and avoids the mindset of, “the consultant told us to do this.”

InfoQ: If you sometimes see where the team is headed, have there ever been any surprises or unintended consequences?

Anderson: I’ve seen teams bring in executives and shown them the resulting diagrams on the wall. It’s a very useful way of explaining how complex systems work, and where there are major dependencies and pain points.

InfoQ: Is the purpose to find the pain points?

Anderson: That isn’t an explicit purpose, certainly not to the extent that it can be with other Event Storming sessions. However, they usually show up, and sometimes where people don’t expect. If you were to ask someone, their opinion will always be biased. The Boris Exercise may show them that the problem they face is actually due to a dependency they didn’t realize existed.

InfoQ: Where did the ideas and names of the exercises come from?

Anderson: The idea for The Boris Exercise came from seeing three skeins of yarn sitting on the desk of a COBOL programmer who liked to knit. The end result is something that looks like a spider web. We eventually replaced yarn with whiteboard tape. The name comes from the song “Boris the Spider,” by The Who.

Snap-E is a quick method creating documentation “in a snap.” Some people assumed there was an acronym, so we decided on “SNAP, Not Analysis Paralysis, Enhanced.”

Article originally posted on InfoQ. Visit InfoQ

While there are many advantages to using Angular for building SPAs, some parts including trivial, static content such as Contact As, Licensing, etc. don’t need the extra complexity. In this article Evgueni Tsygankov shows how to build reusable Angular components that can be hosted in ASP.NET Core pages, allowing you to choose the right tool for each page.

By Evgueni Tsygankov