Chapter 2

Architecting Methods for Cloud SaaS Software – Solutions or Products

2.1  Introduction

Architecting or ‘architecture development’ is still a mixture of art and science. The ‘science’ or to say more precisely the ‘engineering aspect’ is addressed throughout this book in various chapters.

The effort required to develop architecture is large. Various teams will work on different segments of the architecture development project. Yet, a robust method is also essential to coordinate the work among team members and get desired work product, namely, the solution architecture.

Architects need to communicate during the development of architecture as well as post development and throughout the life cycle of realization of the architecture. The communication can be in the form of architectural diagrams or views, but it is very much essential to maintain consistency in communication.

Software architects around the globe have similar needs. The open group fulfilled such needs through a global architecture model The Open Group Architecture Framework (TOGAF) Version 9.1. The architecture development method (ADM) in TOGAF Version 9.1 gives a complete and comprehensive methodology for architecture development. In addition, TOGAF has benchmarked the language, acronyms, vocabulary and taxonomy that are commonly required for architects to exchange and communicate their ideas.

The International Standards Organization (ISO)^[6] has idealized views of the architecture that are necessary to communicate the architecture to various stakeholders.

Thus, we have the basic method of developing architecture from world principle body – TOGAF.

This book presents the following practical use of this generic methodology:

1. TOGAF ADM is the overall architecting methodology that one can put in place for all projects requiring architecture development for cloud Software as a Service (SaaS) solutions or products. TOGAF itself is a framework, and hence any enterprise can adopt it. Its applicability is not limited because of the technology or other reasons.
2. Most of the cloud SaaS solutions will be service-oriented architecture (SOA) based; TOGAF also provides elaborate guidelines on how to use TOGAF with SOA. Reference [28] is in particular useful as it is ‘using TOGAF to define and govern SOAs’.
3. A typical cloud SaaS solution is no longer a ‘point solution’ that will be used by a single enterprise. Therefore, the solution architects have to re-orient themselves. They have to bear in mind single instance of cloud SaaS solution or product that will be simultaneously used by multiple enterprises. Therefore, TOGAF’s ADM should be adopted for this purpose.
4. There are two special classes of potential customers for cloud SaaS product: a. small-or medium-sized enterprises (SMEs), b. ‘long tail’. It will be a new experience for most of the architects to adopt ADM for giving solution to these two segments. This provides one approach that can be used for SMEs.
5. In this ‘agile’ era, many a times architects need to architect cloud SaaS solutions even before requirement gathering begins! This chapter will touch upon how to architect under agile situation where the requirements are not available.
6. Detailed steps to architect for a specific product (or solution) are discussed in Chapter 9.

Reading and understanding TOGAF and its ADM is advisable for better appreciation of the contents of this chapter; and also the content of this chapter is a pre-requisite for reading Chapters 7 through 9.

Based on experiences in various projects, an overall process that can govern the architecture development project for SMEs is summarized in the following Figure 2.1^[19]:

The process has three major stages: (1) before applying TOGAF ADM steps, (2) using TOGAF ADM and develop architecture and (3) post-architecture developments work such as mapping architectural building blocks (ABBs) to solution building blocks (SBBs) etc.

Figure 2.1  TOGAF- and ADM-based process for cloud SaaS architecture development project

The three stages in the above are as illustrated below:

Stage 1

1. Group and structure the required business capabilities

Stage 2

2. Customize TOGAF ADM phase for this specific use:

• Adopt TOGAF ADM for a group of enterprises.
• Adopt ADM phase E’s ‘approach’ for a group of enterprises.
• Customize phase E’s ‘steps, inputs and outputs’.

Stage 3

3. Evolve mapping guidelines for ABB to SBB for cloud-based solutions.

4. Group and order the IT functionalities that are required to realize the business capabilities.

5. Derive ABBs from there.

6. Map ABBs into possible SBBs.

7. List cloud solution criteria.

8. Filter the SBBs after applying above ‘cloud solution criteria’.

9. Build SaaS cloud solution:

• Arrive at hardware configuration for each software.
• Find out scaling parameters for each software.
• Come up with deployment architecture for minimum set.
• Evaluate cloud solution providers, meeting the above architecture. (cloud O/S AWS, Azure, etc.)

This chapter will address the first two phases; Chapter 7 will elaborate with illustration the third phase.

2.2  Cloud SaaS Solution Addressing Business Capabilities of SMEs

Scope of enterprise: Before any architecture development project, it is better to fix boundary of enterprise architecture (EA) it affects or it is involved. Entire EA need not be available^{[2, 3]} to start with before starting any specific architecture project; and in this case, it is about developing cloud SaaS solution architecture for a special group of enterprises – SMEs.

Some special characteristics of SMEs are as follows:

1. As discussed in Chapter 1, most solutions were developed specifically for one single enterprise.
2. Later trend of coming up with software products tried to generalize the requirements across similar industries and address them.

SMEs do not fall under any of the above two categories. They can be grouped under one vertical segment such as textile industry or automobile spare parts industries or leather manufacturing industry. But within the segment, individual enterprises may not produce or offer similar services. Most often, they provide complimentary services such as one company may produce yarn, another company may dye them or third company may only weave or knit. Thus, all enterprises within the community may collectively have the capability of producing a class of end-products; and in this case, vests or pants or shirts. But in most of the cases, one is not a customer or vendor for another within the same community. Thus, none of them have same business capabilities.

Thus, what is the ‘scope of enterprise’ that will use this cloud SaaS solution? – If it is SMEs, it is not one single enterprise or a sub-part of an enterprise; it is a community of enterprises; but solution should be common to all enterprises in the community.

In addition, these enterprises, being small, they individually would not have EA models developed for themselves.

Size and complexity of each enterprise in the community may affect EA model to be assumed within cloud SaaS solution software.

Most enterprises within the community are smaller and less complex in business operations; but that naturally allows them to adopt common sharable community cloud SaaS capabilities.

For such a situation, it is better to adapt one important recommendation of TOGAF; that is to develop first, a strategic (enterprise) architecture that gives a summary of formal description of the enterprise. Then, identify and recognize particular segments of enterprise to which a business capability is demanded. Cloud SaaS solution will address that capability (e.g. enterprise resource planning (ERP) or human resources management (HRM)).

Enterprise architects could then develop segment architectures (which can define the scope of enterprise for the current architecture project). In each segment, one or more specific business capabilities can be achieved through cloud SaaS solutions. Scope of enterprise will comprise all these segments.

2.3  Adopting TOGAF’s ADM Phases for Cloud SaaS Solution

This section gives an example of how to adapt TOGAF ADM when developing cloud SaaS solutions for SMEs. This is not intended as a self-standing description; and should be read in conjunction with activities and other details found in each phase of TOGAF ADM Version 9.1^[4]. The adaption discussed here is based on a couple of real-life experience.

2.3.1  Phases – Preliminary Phase to Phase A–D

2.3.1.1  Preliminary Phase

The preliminary phase is where architecture capability should be adapted to support cloud computing reference architecture (CCRA) (e.g. draft proposal from IBM^TM) and SOA reference architecture. Key outputs of this phase are (architecture, governing or organization) principles, organizational structure, governance and initial content of the architecture repository^[4].

Architecture principles will come from two reference architectures mentioned above. A few more will come due nature of ‘enterprise segment’ that the solution aims to address. For example, one architecture principle can be ‘complete shield of information not to be revealed to any other member enterprise within SME community’. This will be segment specific such as textile or retail or leather manufacturing, sometime stipulated by main stakeholders of the community of SMEs.

2.3.1.2  Phase A: Architecture Vision

Business vision is normally obtained in the context in which business is asking to develop cloud SaaS solutions.

For example, when Indian economy was opened to international economy, all Indian enterprises have to compete in global market with internationally repute enterprises whose business capabilities have matured a lot.

Therefore, one of the communities of Indian SMEs enterprises set a business vision to empower these SMEs to have business capabilities to be on par with big enterprises and compete equally with them in the international market place^[1].

Some example business capabilities are international-level ERP and management, financial management and transparency, and HRM. Such specific business vision is essential.

A consortium of small or medium banks in Europe set a business vision of keeping their operating cost as low as possible, by commonly sharing all possible computing resources for conducting their ‘new customers account-opening operations’.

2.3.1.3  Phase B: Business Architecture

Building Business Capabilities for a Group of Enterprises

In tune with the business vision, cloud SaaS solution should aim to build and provide required business capabilities.

This section explains how it is different to build a solution for group of enterprises (SMEs in particular) and the challenges involved in it.

The first challenge is that the cost of solution will restrict from providing ‘all capabilities’ that a large enterprise can afford to. But there is no way to escape from providing ‘all capabilities’. Any given enterprise in a community may need or use only a small subset of entire business capabilities; but the cloud SaaS solution needs to provide all capabilities. This is because sum total of individual company’s requirements will add up to ‘all capabilities’, and sometimes it may even exceed that. Therefore, cloud SaaS solution architects need to plan for providing ‘all capabilities’; but it can plan to implement them in parts as per the demand for each part comes up.

In a way, they need to think like product architects to provide a complete solution that can compete in the market community.

The second challenge emerges from the fact that existing capabilities of each enterprise in this group may vary vastly. Therefore, any assumption on ‘as-is’ capability of any enterprise within the community may be erroneous.

The third challenge was in grouping the demanded capabilities.

A possible solution to this third challenge is explained below:

1. One way is to group them in an order-of-maturity from small or medium enterprises. As the enterprises grow and matures to provide higher level services, they may need higher level business capabilities.
2. The second way is to group all the required capabilities of small enterprises or medium enterprises into a separate bucket. For each enterprise, the capabilities required can be further divided into two sub-categories:
   1. Very specific to an enterprise
   2. Common to most of similar enterprises in the community
3. The third way is to group them in terms of similar products or services produced by enterprises irrespective of their size – small or medium; and then group them as per point (ii), then within that group as per point (i).

The given list of requirements has to be analysed in the above three ways before finalizing one model.

At a minimum, the above-mentioned ways of grouping capabilities are essential to identify the correct set of ABBs. The grouping is also to plan to allow customization features of business capabilities.

The above is a simplified application of what is discussed in Chapter 20 of TOGAF ADM Version 9.1^[4].

2.3.1.4  Phase C: Information Systems Architectures

This phase consists of two sub-phases: Development of data architecture and applications architecture^[4].

Cloud SaaS solutions need a special attention and development effort for data architecture. This is discussed in Chapters 5 and 9.

Chapters 7 and 8 give prime importance to explain application architecture. The finer details that need to be taken care of in architecting cloud SaaS solutions are discussed in Chapter 9.

2.3.1.5  Phase D: Technology Architecture

The technology architecture defines the software and hardware infrastructure that are needed to support the cloud SaaS solution. This is covered in Chapters 4, 7, 8 and 9.

The starting point is CCRA which is discussed in Chapter 10. Chapter 9 indicates how to make use of the CCRA.

2.3.2  Phase E: Opportunities and Solutions

2.3.2.1  Phase E for a Group of enterprises

Adopting TOGAF’s ADM Phase E for architecting cloud SaaS solutions for a group of enterprises (SMEs) can be explained in three paragraphs:

1. Adapting TOGAF ADM Phase E ‘approach’.
2. What are all applicable ‘steps, inputs and outputs’ of phase E in this context.
3. Discussion about ABB to SBB mapping guidelines for cloud-based solutions in brief. This step is elaborately discussed in Chapter 7, and hence not discussed here.

2.3.2.2  Adopting TOGAF ADM Phase E’s ‘Approach’

The following figure^[19] summarizes three important points:

1. ‘Standard approach’ column summarizes essential points in TOGAF grades ‘approach’ that we could not adopt without modifications.
2. The second column summarizes key factors that influence adaption of the basic approach. These factors are specific to SMEs. In reality, there may be many more.
3. ‘Adopted approach’ column summarizes resultant modified points.

(Existing building blocks and EA may not be available.)

(The steps and procedures mentioned here can also be adopted for re-architecting even (home grown b-spoke or custom) enterprises systems to make them fully cloud compatible SaaS software and host them on IaaS platforms.)

The above figure can give some idea of adopting the ‘approach’; but that is not the end of it. Although the above is an extract from real-life project, individual project teams may need to do a lot of work in this area for their specific projects.

2.3.2.3  Customizing Phase E’s ‘Steps, Inputs and Outputs’

The following table^[4] highlights some of the mostly used ‘steps, inputs and outputs’ in cloud SaaS architecting projects.

*At this stage, architect would also need to review of non-functional requirements/parameters to meet the functional specifications. But TOGAF will not give these finer detailed steps.

 

The following are simple explanations of the above table:

1. If the customer segment is SMEs, except two steps (which are highlighted in bold in Column 2 of the table above); all others cannot be directly executed. This is mainly because customer is a ‘group of enterprises’ and not a single enterprise. Some of these omitted steps have two components. One is very specific to an enterprise and the other is common across all enterprises in the community. The common ones were collected and carefully examined before providing solution in a separate sub-project.
2. For example, the prescribed step ‘Determine/confirm key corporate change attributes’ had to be deferred until a particular enterprise subscribes to a sub-set of the solution. The ‘change attributes’ need to be decided for that enterprise based on the chosen services.
3. Similarly, all required inputs will not be available at all or at the beginning of the project. Examples of the ones available are highlighted in Column 3.
4. However, it is up to the architect to come up with all possible and necessary outputs; these are highlighted in Column 4.

2.3.3  Remaining Phases in ADM

2.3.3.1  Phase F: Migration Planning, Phase G: Implementation Governance and Phase H: Architecture Change Management

Most of the steps are very much like any other architecture project. However, a few factors already discussed such as the following:

1. multiple tenants using same single instance of software or
2. nature of the customers group – may be ‘long tail’ or SMEs or other verticals

will have some or other impact in these phases; but, they become mostly project specific, if any. Therefore, it is not discussed here.

That brings to an end of our discussion on adapting ADM for architecting cloud SaaS solution.

2.4  Agile Architecting Method

This additional architecting method^[17] summarized here will be of definite relevance and use to the readers.

The project situation: requirement gathering has inherent difficulties in cloud SaaS project

1. For most (cloud SaaS) product development projects functional specifications will not be given by a single person or by a single enterprise; neither anyone will sign off functional specification document. For architects moving from traditional enterprise projects experience, this itself will be quite a shocking experience.
2. Even for conventional software product development company, finding functional specification is not going to be easy. They have to synthesis functional specification from many enterprises in the same industry segment. But many product vendors have got used to this and successfully got over this hurdle to develop industry-specific solutions or products.
3. For cloud SaaS solutions, the ambiguity in freezing functional specs is much larger than what is discussed earlier:
   1. Most of the time, business could adjust functional requirements based on how customers are using/consuming cloud SaaS services. This should come either from use of previous similar solutions, or it will be known after cloud SaaS solution is launched and customers begin to use the same.
   2. If customer segment is SMEs or ‘long tail’, the average literacy levels of users may affect usage pattern and participation from them in terms of expressing their feedback or desires for modifications of cloud SaaS solutions.
   3. Very rarely organized communities of enterprises could spell out their requirements more clearly up front by employing professional bodies to collect their requirements and specify to service provider. But, if cloud SaaS providers have to collect the requirements on their own initiative, then requirement gathering is a difficult proposition as individual enterprises will not spare their time or effort to provide the same.

All these will demand a strong team that has deeper knowledge across industry, domain, vertical and a thorough understanding of the domain problem for which solution is sought, to spell out the ‘requirements’ in the final cloud SaaS solution.

In addition, architects should be ready to accommodate changes in functionalities and capabilities post launch of the service based on user feedback.

Such a situation alarms since the architecture needs to be flexible to take those changes.

At the first place, it is better and desirable to come up with a ‘flexible architecture’ – if anything called ‘flexible architecture’ – to accommodate such challenging requirements that may come as a surprise after launch.

In addition to the above situation of ‘where to go for’ functional and non-functional requirements, agile methodology expects the coding to start from day one of the project start. Where is the time for collecting requirements, freezing it and then start architecting and then designing, etc., as in waterfall method of software development life cycle (SDLC)? In the conventional SDLC method, architecting starts after requirements are frozen.

These challenges are more common in cloud SaaS development projects.

Therefore, architecting has to happen in parallel to requirements gathering. May be the architecture will serve as input for even collecting requirements!; this could be a practical approach. This implies that cloud SaaS software architecture should be ready and available even before requirements gathering is initiated.

We will see how to architect under these project situations. Let us review an ADM for this situation.

Reference [17] discusses the same method with an illustration. Chapter 10 makes use of this knowledge and also gives finer details of this method.

Method

There are two starting points for developing architecture under the above-mentioned condition:

1. Start collecting requirements and identifying ABBs for the solution.
2. Start architecting by employing knowledge from TOGAF.

2.4.1  Requirements Collection and Identification of ABBs

There are two main streams of activities that one may follow the other: They are as follows:

1. Requirements collection for cloud SaaS software.
2. Domain knowledge and identification or recognition of ABBs.

Some of the domain knowledge and problem for which the cloud SaaS solution is being applied, will help identify or recognize a bunch of requirements. For example, one can recognize that we need a product catalogue or tax calculating engine if we are attempting e-commerce-related solution.

From the ecosystems in which solution is going to exist, architects can visualize another bunch of requirements; for example, interfacing-module requirements can be identified for information exchange, assuming the solution need to work closely with other enterprise systems.

Identify the common services/components of the intended application software at early stage of cycle, which is less prone to change. However, all common services required to build and provide SaaS will be default from or available in CCRA as Chapter 10 explains.

On elaborating problem statement and also from architects knowledge and experience, architects can visualize a few more ABBs. For example, an ordering system will naturally have customer-specific pricing algorithm. It may even warrant an e-commerce module.

All the above steps may not result in any specific frozen requirements; but it will help in recognizing a need for a module or bunch of requirements that can appear as ABBs.

2.4.2  Architecting by employing Techniques from TOGAF

TOGAF ADM and the body of knowledge centred on TOGAF gives a lot of clues to recognize or identify architectural components; this is very handy to develop architecture in this situation where requirements are not available before architecting.

Reasonably, detail level of architecture can be developed by following steps discussed below:

1. Applying principles of EA continuum^[30]
2. Trying to utilize domain architectures available in open literatures
3. Using EA
4. Utilising CCRA
5. Deriving Architectural components from SOA reference architecture
6. Adapting multi-tier distributed architecture
7. Finalizing technical environment of the solution
8. Identifying SBBs

These steps need to be executed more or less in the same sequence as they appear above. However, these steps can be carried out in parallel to ‘requirements gathering and ABB identification steps’.

(i) Applying principles of enterprise architecture continuum

The enterprise continuum enables organization of reusable architecture artefacts and solution assets

Enterprise continuum can be imagined as a repository of all architectural assets^{[29, 30]}. These include architecture descriptions, models, building blocks, patterns, viewpoints and other artefacts that exist both within the enterprise and in the IT industry at large, which the enterprise would like to have them available for themselves for the development of architectures^[30].

The architecture continuum (Figure 2.2) illustrates how architectures are developed and evolved across a continuum ranging from foundation architectures, through common systems architectures, and industry architectures, and to an enterprise’s own organization-specific architectures (In our case, it can mean the cloud SaaS solution architecture).

Figure 2.2  Architecture continuum. Reproduced from Ref. [30] with permission

Enterprise needs and business requirements are addressed in increasing detail from left to right. Architects will typically look to find re-usable architectural elements towards left of the continuum. When elements are not found, requirements for the missing elements are passed to the left of the continuum for incorporation. Those implementing architectures within their own organizations can use the same continuum models specialized for their business.

Notes: That means there may be many re-usable architectural components available in the repository either within or outside enterprises. Identifying them is essential. Marking those that are not existing becomes part of the new requirements. This is also a good way of checking completeness of requirements!

“The TOGAF ADM describes the process of developing an enterprise-specific architecture and an enterprise-specific solution(s) that confirm to that architecture by adopting and adapting (where appropriate) generic architectures and solutions (left to right in the continuum classification). In a similar way, specific architectures and solutions that prove to be credible and effective will be generalized for re-use (right to left in the continuum classification)”.

Clippings from TOGAF on architecture continuum^[30] only assures that any solution architecture does not exist in isolation. It is a point in a continuum space of architecture. This only conveys to practising architects that he or she need not (re)invent most of the architectural components that are necessary for a specific project; most of the pieces will be available somewhere there.

In any given architecture development project, only the missing components for which requirements are raised may have to be developed; and other components need to be taken from internal (to enterprise) or external repository of components, and they have to be tweaked, if necessary, and adapted for the specific project.

The first step is identifying the point in space as to where the solution lies. This will naturally follow collecting all reusable existing architectural components relevant to the project on hand.

In addition, during the same time, it is advisable to collect architectural components of adjoining pieces of the solution too. These will let architects know about interface requirements and the required components in the solution architecture.

Architects need to look for these components both from within (SaaS providers as well as customers or the specific industry) enterprise as well from outside enterprise.

It is worth investing time and effort to locate these components from various repositories, and that is one of the ways of bringing best practice and matured and tested components into the solution architecture.

This is the first source of information for an architect to begin developing architecture, even before requirements are ready.

(ii) Trying to utilize domain architectures

Domain architectures are those that may be available outside enterprises. Architectures within enterprises are interpolation to domain architecture as detailed in EA continuum discussed earlier in this section.

There are domain-specific architectures such as NGOSS for telecom. Similar ones are available for retail industry.

These domain architectures are again another quite useful source to pick necessary architectural components for the project. Domain architectures also help in specifying where the specific cloud SaaS architecture that is being developed fits in the continuum.

The solution’s position in domain architecture will give some more top-level descriptions about requirements from domain perspective.

In addition, the domain architecture can explain about possible grades that are available to which this intended specific solution needs to fit in.

Therefore, examining respective domain architectures, where cloud SaaS solution fits in, will help in identifying some more relevant architecture components for the solution.

(iii) Using enterprise architecture

Here, EA can refer to two different repositories:

EA repository of

1. Cloud SaaS provider
2. Cloud SaaS consumers or customers

Providers EA repository may contain many architecture components that can be reused for the specific project: such as architectural principles, reusable components, guidance for architecture practice, etc.

Customers in long tail or SMEs segment may not even have any EA practice or repositories established. Therefore, architects cannot expect any reusable component from them.

Sometimes, big enterprises (consumers) EA repository may have useful reusable components. Unfortunately, it may or may not be available for providers for the purpose of their use.

If any of these architectural components are available in open source or published media, then that can also serve the purpose. Architectures from SaaS consumers will give enough clues, specifications and functional requirements to guide architectural components such as those for interfacing with customer systems.

In addition, it will give a good direction on the usefulness of the solution – the missing piece in the puzzle of enterprises capabilities too. That verifies demand for this service.

(iv) Utilizing CCRA

1. Chapter 10 gives a quick review of CCRA that is proposed by IBM^TM and under review by TOGAF.
2. CCRA gives default architecture for any cloud SaaS software.
3. This is a good starting point for most of the architecture projects.
4. Architects need to start with this default generic architecture and need to work on it to obtain specific solution architecture.
   1. Review all architecture components in the reference architecture.
      • Retain those that are essential for a specific project.
      • Identify those components that need to be modified to adapt to the specific project.
   2. Find SBBs for default and necessary common services that are finalized for specific solution.
   3. Fill functional layer with services that the final cloud SaaS solution needs to offer to customers.

(v) Deriving architectural components from SOA reference architecture

1. A good knowledge of SOA is essential for all cloud SaaS solution architects.
2. TOGAF provides SOA reference architecture.
3. Since cloud SaaS is basically (software as) a service, SOA knowledge is inevitable.
4. SOA RA will give additional architecture principles and other architecture components necessary for completing cloud SaaS solution.
5. On adapting CCRA, automatically one is into SOA. CCRA is a super set of SOA RA by including those that are essential for cloud computing. However, being aware of the fact that CCRA is a super set of SOA RA will help in not missing any architectural components.
6. All these need to be added to the architecture asset repository.

Chapter 9 discuss this in further detail.

(vi) Adapting multi-tier architecture

Multi-tier architecture or n-tier architecture is a generalization of three-tier architecture.

The multi-tier architecture style guides and provides place holders for identified ABBs on its various tiers. Multi-tier architecture is a fundamental to provide a cloud SaaS solution. Chapter 10 provides tier-wise details relevant to cloud SaaS software architecture.

(vii) Technical environment of solution

Technology choice and platform will also give a lot of necessary ABBs and components for the architecture. For example, if it is decided to support mobile devices apart from desktop clients, there is a need for corresponding module on the Web tier.

(viii) Identify SBBs

Last but one step in architecting is to identify SBBs.

This involves identifying third-party products, plugins and specific engines that are matching and helpful to realize ABBs.

For some of the benchmark components such as BSS or OSS, there may be basic COTS or open sources available in the market.

SBBs corresponding to business functionalities addressed specifically by the solution need to wait until all functional requirements are frozen. In that sense, mapping those ABBs to SBBs need to wait until requirements are almost finalized. Chapter 7 provides special techniques that can be adapted for mapping ABBs to ABB in cloud SaaS solution projects.

Concluding remarks in the method:

The above steps in this particular track give specific architecture and its components.

These steps work like a funnel. It all starts with a very generic and high-level architecture; then, it becomes more specific architecture for a given cloud SaaS solution as the architects take the architecture through these steps from a–h.

ABBs that come out of requirements analysis also get mapped into this skeleton architecture.

Requirements that are being gathered, during and also after development of architecture, will be mapped onto envisaged individual-specific ABBs.

If any existing or identified ABBs cannot accommodate any new incoming requirement, then new ABBs can be created.

The software architecture at this stage can also be used for collecting remaining details of requirements.

Architecture principles, identified other architecture components, envisaged building blocks and recognized ecosystem – all the above will give enough of information for architects to figure out connections required to connect the building blocks and components in the architecture.

Thus, the architecture at this stage will have enough details. The nitty-gritty details of functional requirements will not alter this first good draft Architecture.

This Architecture needs to be reviewed when details of non-functional requirements arrive. Most of the time non-functional requirements are estimates for cloud SaaS solutions based on the experience of the Architects team.

2.5  Summary

• This chapter points out that TOGAF ADM can be a core method that can be put in place for any cloud SaaS architecture development project.
• This chapter provides two architecting methods that are adapted from ADM for two specific situations:
  • One is for cloud SaaS architecture development projects for a community of enterprises of small- or medium-sized enterprises. Therefore, the first section of this chapter shows how to adapt TOGAF’s ADM for developing cloud SaaS solutions or products for SMEs.
  • The second one describes how to develop architecture under agile conditions such as in cases where even the requirement is not ready.
• Although these two may outwardly appear to be special cases, these methods along with TOGAF’s ADM will help architects to figure out one for their organization as well as to their specific project.