Notes by Ian De Silva
Software Development Improvement Program: Enabling Software Excellence at a Hardware Company
Sascha Stoeter, ABB
ABB has historically been a hardware company, but it has been slowly increasing the amount of software development it does since the 80s. It is a distributed company (in 34+ countries) with software embedded into products such as controllers. Each team has its own set of tools to support development efforts.
Sascha et al. are trying to transform this company, making it a software power house, and building a community to leverage knowledge and improve performance within the company. To support the transformation, they started by establishing communication and sharing networks such as newsletters, internal community-driven question-and-answer forums, and a training and information page. They then attempted to improve practices by providing training and a team assessment method to identify problem areas. This assessment method emphasizes static analysis, coding standards, and other “best practices.” This effort was then supported by tools unification, providing a set of tools for all organizations to use.
Sascha et al. also emphasized training taking a multi-pronged approach. They made e-learning available to employees to refine their skills; they also used the communication channels they’d established earlier to deliver additional training. The most effective and well-attended approach, however, was webinars and courses held concurrently around the globe. They found that the webinar attendance is constantly increasing. This is remarkable because software development is not consolidated into a business unit; rather, it is part of hardware development organizations.
In all, there is still significant work to be done to complete the transformation, but the steps taken by ABB have been promising.
Mission Thread Workshop (MTW): Preparation and Execution
Tim Morrow, SEI
- the meeting
To prepare for the MTW meeting, the organization must express the system’s functionality as a mission thread (or system use case). The system-of-system’s mission purpose and business value must be described. The organization must answer questions like “What is driving the system?” and “Why is this system of systems necessary?” The architectural vision must be expressed along with the system-of-system’s scope and constraints. For each mission thread under consideration, the organization develops one or more vignettes, or step-by-step use scenarios, that enable communication between the team and the other stakeholders. Each vignette should also describe the actors and nodes involved in the scenario, as well as any assumptions. To complete preparation, the quality attributes and stakeholders must be identified for the system of systems. For stakeholders, the architect, modeler, program manager, and end-users must be included.
The MTW meeting takes about 1 to 1.5 days and consists of presenting the architectural plan, reviewing the mission threads and vignettes, and, finally, augmenting the mission threads with feedback and quality attributes.
After the MTW meeting, the mission threads and vignettes are cleaned up, and all comments and challenges are addressed. Before being addressed, the challenges are grouped and organized into challenge areas. Each of these challenge areas is then analyzed, and recommendations are formed to address the challenge.
Mission threads support the architecting of systems of systems. Leveraging the mission threads, the architect can walk through the use scenarios, improving the architecture.
Enterprise Architecture for the “Business of IT”
IT can be viewed as value chain (a process) with functions, services, and management data. This view is used to support running a help desk, portfolio management, or other operational applications. Charlie needed an architecture to define the system of record for the help desk, the portfolio management, etc.
At Wells Fargo, Charlie, identified four lifecycles:
- application service
- asset (the licenses and instances for the actual software)
- technology product (the actual software)
IT services is a delivery of transactional value, but also a human who defines its value, its “moment of truth.” These IT services are a system of systems: there are application services running on infrastructure services, running on the assets or instances of a technology product.
Charlie defines a lifecycle for the inception through retiring of IT services. This provides a clean vocabulary for the process of developing IT services. Thus, both the process and the system of systems provide different IT value: the customer value and the IT value.
How can we evaluate this value, or more importantly, measure improvements? There are numerous things that can be measured such as lifecycle value, quantity of security breaches, data quality, etc. For this, we look at the function-decomposition view of the system to help. Unfortunately, without historical data as our baseline, we cannot measure improvements. With historical data, an understanding of all four lifecycles, and an understanding of the business architecture, you should be able to build reports to identify both risks and costs.
In summary, Charlie presented on a model for the IT business. From this work, he found that if you optimize portions of the system, the entire system will be less than optimal.