Using Obstacles for Systematically Modeling, Analysing, and Mitigating Risks in Cloud Adoption

In this chapter, the authors motivate the need for a systematic approach to cloud adoption from the risk perspective. The enormous potential of cloud computing for improved and cost-effective service delivery for commercial and academic purposes has generated unprecedented interest in its adoption. However, a potential cloud user faces numerous risks regarding service requirements, cost implications of failure, and uncertainty about cloud providers’ ability to meet service level agreements. Hence, the authors consider two perspectives of a case study to identify risks associated with cloud adoption. They propose a risk management framework based on the principle of GORE (Goal-Oriented Requirements Engineering). In this approach, they liken risks to obstacles encountered while realising cloud user goals, therefore proposing cloud-specific obstacle resolution tactics for mitigating identified risks. The proposed framework shows benefits by providing a principled engineering approach to cloud adoption and empowering stakeholders with tactics for resolving risks when adopting the cloud.

Software Architecture Practices in Agile Enterprises

This chapter is based on the results of a survey carried out in 11 IT companies in Finland in Fall 2010. In this survey, the existing practices regarding software architecting work in agile enterprises using Scrum are mapped out. Four main practices to cope with software architecture in Scrum are identified and analyzed. The adoption of these practices is discussed in relation with the characteristics of the teams and project types. Further, the interaction of these practices and Scrum patterns is analyzed. The results indicate that most of the found practices are in conflict with Scrum. The analyzed relationships between Scrum patterns and the identified architecture practices help to understand how software architecture work is aligned with Scrum in real life, as well as the problems of the practices from the Scrum point of view.

Linking Business and Application Architectures

The development of an IT strategy and ensuring that it is the best possible one for business is a key problem many organizations face. This problem is that of linking business architecture to IT architecture in general and application architecture specifically. Without this linkage it is difficult to manage the changes needed by the business and maximize the benefits from the information technology (IT) investments. Linking the two domains requires defining the two architectures using a “common language.” While the application architecture domain has developed tools and processes to define and represent the architecture, the business architecture domain, however, lacks such processes and tools to be useful for linking of the two. The chapter addresses several questions dealing with the linking of the business and the application architectures. The author proposes to use category theory related constructs and notions to represent the business and information architecture and the linkages.

Decisions Required vs. Decisions Made

Contemporary enterprise architecture frameworks excel at inventorying as-is and at specifying to-be architecture landscapes; they also help enterprise architects to establish governance processes and architectural principles. Solution architects, however, expect mature frameworks not only to express such fundamental design constraints, but also to provide concrete and tangible guidance how to comply with framework building blocks, processes, and principles – a route planner is needed in addition to maps of destinations. In this chapter, the authors show how to extend an existing enterprise architecture framework with decision guidance models that capture architectural decisions recurring in a particular domain. Such guidance models codify architectural knowledge by recommending proven patterns, technologies, and products; architectural principles are represented as decision drivers. Owned by enterprise architects but populated and consumed by solution architects, guidance models are living artifacts (reusable assets) that realize a lightweight knowledge exchange between the two communities – and provide the desired route planners for architectural analysis, synthesis, and evaluation.

Using Genetic Algorithms to Search for Key Stakeholders in Large-Scale Software Projects

Large software projects have many stakeholders. In order for the resulting software system and architecture to be aligned with the enterprise and stakeholder needs, key stakeholders must be adequately consulted and involved in the project. This work proposes the use of genetic algorithms to identify key stakeholders and their actual influence in requirements elicitation, given the stakeholders’ requirements and the actual set of requirements implemented in the project. The proposed method is applied to a large real-world software project. Results show that search is able to identify key stakeholders accurately. Results also indicate that many different good solutions exist. This implies that a stakeholder has the potential to play a key role in requirements elicitation, depending on which other stakeholders are already involved. This work demonstrates the true complexity of requirements elicitation – all stakeholders should be consulted, but not all of them should be treated as key stakeholders, even if they appear to be significant based on their role in the domain.

Mitigating Mobile Diversity with RESTful Services

Mobile devices create new opportunities for companies. However, innovative applications can cause challenges for software and system architecture. In this chapter, the authors describe a trap to fall into when starting a promising mobile application in a shortsighted way. When the application gets popular and successful, diversity of mobile platforms increases. Many users have an almost emotional relationship to their own smartphone or platform and may not be willing to change it. In order to make the mobile application available to more users, a company may be tempted to add a “simple” extension to accommodate other platforms. Thus, the diversity in devices leads to diversity in distributed object technologies and with it to problems in complexity and compatibility. The authors describe an approach that counters this problem with RESTful services. They use the ConTexter system for illustrating experiences with the problem and for evaluating a proposed solution. The chapter shows the key issues the authors had to solve while migrating ConTexter to a RESTful platform.

Evolutionary Architecting of Embedded and Enterprise Software and Systems

Many industries rely heavily on embedded software and systems to maximize business value in their products. These systems are very complex, and the architecture is important to control the complexity and make development efficient. There are often also connections between the embedded system and the different lifecycle processes, and hence, to the enterprise systems supporting those processes. It is rare to start from scratch when developing new products, and instead, these companies evolve their products over time, which means that architecting needs to be evolutionary. This chapter describes what such an evolutionary architecting process can look like based on observations from industry, and how the process can be continuously improved using a maturity model. It is also presented how the embedded system relates to different elements of the enterprise architecture.

Relating Enterprise, Application, and Infrastructure Architects

The architect takes a high-profile role in many IT departments today. In fact, it can be quite difficult in some organizations to find a senior member of IT technical staff whose job title does not include the word “architect.” However there is little consensus in the academic community or amongst practitioners as to the responsibilities of the many different types of architect we encounter – or indeed, what they should even be called. In this chapter, the authors propose a simple, widely applicable taxonomy of architects, namely enterprise architects, application architects, and infrastructure architects. The authors define distinguishing characteristics, their responsibilities, the stakeholders with whom they engage, and the tools and techniques they use. The chapter shows how this taxonomy can be applied to most, if not all, practicing architects in the information systems domain, and explains how it helps us understand how such architects work together to help deliver the organization’s business goals.

High-Level Modeling to Support Software Design Choices

The IT industry is suffering from severe budget overruns and ill-performing IT services. Some of the problems that have caused IT project disasters could have been anticipated in the early project phases and mitigated in the project follow-up by modeling the system context and the software design. This chapter shows how to make models of varied views and at varied levels of abstraction to guide software design choices. Models of the enterprise provide understanding of the objectives. Models of the specification provide understanding of system performance and behavior. Models of the design provide understanding of design choices, such as the allocation of functions, resource usage, selection of mechanisms for communication, instantiation, synchronization, security, exception handling, and many more aspects. High-level models are simple models with the primary goal to support understanding, analysis, communication, and decision making. The models have various complementary representations and formats, e.g. visual diagrams, mathematical formulas, and quantitative information and graphs. Model-driven and model-based engineering approaches focus mostly on artifacts to analyze and synthesize software and hardware. High-level models complement model driven approaches by linking the system context to more detailed design decisions. High-level modeling as discussed in this chapter is based on research performed in industrial settings; the so-called industry-as-laboratory approach.

Contexts and Challenges

Historically, architecture has been about the structure of the solution, focused on the components that make up a system and the connectors which enable their coordinated interaction. Given this solution focus, systems, enterprise, and software architecture evolved in different directions. During the past 15+ years, architectural theory and practice have been undergoing a gradual, but significant, shift in focus. Five trends which highlight this shift are: decision rationale, challenges vs. requirements, systems-of-systems, contextual analysis, and design cognition. Each of these trends facilitates a necessary shift from the architecture of the solution to the architecture of the problem. In addition to enabling a clearer link between the problem and solution, these trends also help to unify systems, enterprise, and software architecture by providing a common foundation for collaboration on complex problems.