Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

This chapter concentrates on two initiatives that are capable of bringing business benefits to small and medium companies, that is, enterprise architecture and software process improvement. In recent years, there has been an increasing interest in enterprise architecture (EA) that is widely referred to as an essential instrument for ensuring an enterprise’s agility, consistency, compliance, efficiency and business and IT alignment (Kunstova 2011). Although enterprise architecture is mostly applied by large companies, this chapter shows that it might be worthwhile for small and medium companies as well.

Software process improvement (SPI) is a way of improving a status of software development which is in these days still not satisfactory enough. International standards like ISO/IEC 12207 (2008), ISO/IEC 15289 (2006), ISO/IEC 15504 (2004) and ISO 9001 (2008) play an important role in SPI initiatives as companies are willing to show compliance with common business rules. However, it was identified that small companies find it difficult to implement international standards as they do not have enough resources, in terms of number of employees, budget and time (Laporte et al. 2006; Anacleto et al. 2004). To solve these difficulties, the ISO/IEC 29110 standard “Lifecycle Profiles for Very Small Entities” is being developed.

In this chapter, the author presents a possibility of an added value which lies in the combining of software process improvement and enterprise architecture initiatives. Second part of this chapter examines the role of enterprise architecture and current status of its adoption worldwide and also in the Czech Republic. In the third part, the most accepted EA framework TOGAF is briefly described, which is recommended by the author for usage in small and medium companies. Fourth part presents reasons for developing the ISO/IEC 29110 standard “Lifecycle Profiles for Very Small Entities” and explains its main concepts and structure. The main contribution of this chapter consists in the fifth part where relationships between enterprise architecture and software process improvement are outlined, and an EA framework for SMEs is presented.

2 Current Status of Enterprise Architecture Adoption

A large number of methods for enterprise architecture management have been developed by academia and practitioners so far. These methods are mostly referred to as frameworks. According to ISO/IEC 42010:2007, “An architecture framework establishes a common practise for creating, organizing, interpreting and analysing architectural descriptions used within a particular domain of application or stakeholder community” (ISO/IEC 42010:2007). To the well-known frameworks belong, for example, TOGAF, the Federal Enterprise Architectural Framework (FEAF) (Information Officer) Council 2001), the Gartner EA Framework (2005), the Department of Defense Architecture Framework (DoDAF) (DoDAF Working Group 2007) and the Zachman Framework (Zachman 1987).

The results of the Cutter Consortium survey conducted in 2010 (Rosen 2011) show a current status in the enterprise architecture domain. 148 respondents took part in this survey, 47 % coming from North America, 21 % from Europe, 10 % from Australia/Pacific, 6 % from Asia and 16 % from other locations. Company sizes ranged from having fewer than 10 to more than 1,000 IT employees. This survey indicates a growth of experience with EA as 93 % of respondents stated that they already use EA or are just starting to. The main reasons resulting in this growth represent “the increased complexity of IT, the cloud, Enterprise 2.0, other new technology options, as well as the need for more flexible IT systems and reduction in IT costs”(Rosen 2011). Thiry-four percent of respondents that use EA stated they utilise TOGAF because “it is the only standards-based, general-purpose framework that can provide a ready set of principles, processes, and structure for organizing architecture programs” (Rosen 2011). Further, 29 % of the respondents take advantage of combining various EA methods, 3 % utilise Zachmann, 2 % utilise DoDAF/MoDAF, 17 % use other methods and 16 % apply none. In spite of the convincing win, “the general-purpose nature of TOGAF also provides one of the biggest challenges, as organizations need to tailor large, generic content down to the subset that meets their individual needs and goals” (Rosen 2011).

Seeing a broad adoption of EA worldwide, our team at the Department of Information Technologies of Prague University of Economics started wondering about the situation in the Czech Republic. Therefore, during 2010, we decided to conduct a nationwide survey focused on various characteristics of IS/ICT management. Even though the scope of the survey was quite large, there was a part concentrating on the usage of various architecture views (architectures) in companies. Respondents composed of companies of various sizes were divided according to the number of employees into three groups – small companies with 10–49 employees (14 respondents), middle-sized companies with 50–249 employees (175 companies) and large companies with more than 250 employees (81 companies). We questioned the companies about the types of architectures being used. Among the possible answers that appeared include business-process architecture, architecture of IT services, application architecture, data architecture, technology infrastructure architecture or none of them. Results in a graphic form are shown in the Fig. 20.1.

Fig. 20.1
figure 00201

Percentage of using various types of architecture in small, medium and large companies

Full size image

Surprisingly, we found out that the percentage of small companies using architectures is the same or even higher than in medium and large companies. Every small company in the sample utilises at least one architecture view. Moreover, 21 % of them use all architectures, which overreaches the number in medium (7 %) and large companies (14 %). Detailed analysis of these results showed that each small company that makes use of all architectures is either a local branch of a foreign company or has its seat abroad. Companies that apply all types of architecture are likely to operate in the EA domain and would be a subject of the next survey focused specifically on enterprise architecture.

3 TOGAF

As stated before, the most popular EA framework nowadays is the Open Group Architecture Framework (TOGAF). TOGAF, created by members of the Open Group consortium, is an enterprise architecture framework that emerged during the last two decades “with the objective of becoming a standard for EA development” (TOGAF).

According to TOGAF, framework is “a structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness” (TOGAF). In this sense, TOGAF determines four architecture domains: Business Architecture, Data Architecture, Application Architecture and Technology Architecture. A key component of TOGAF is the Architecture Development Method (ADM), which provides full guidance for implementing and executing an organisation’s enterprise architecture. The process consists of multiple, consecutive phases enclosed in a loop (see Fig. 20.2).

Fig. 20.2
figure 00202

TOGAF ADM (TOGAF – The Open Group Architecture Framework)

Full size image

The preliminary phase encompasses the preparation and initiation activities for EA. Phase A, the initial phase of a cycle, includes defining the scope, identifying the stakeholders, creating the Architecture Vision and obtaining approvals. Phase B concentrates on the development of a Business Architecture, whereas phase C on the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures. Phase D is focused on developing of the Technology Architecture for an architecture project. Phase E conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. Phase F formulates transition architectures. Phase G provides an architectural oversight of the implementation. Phase H establishes procedures for managing change to the new architecture. Requirements management examines the process of managing architecture requirements throughout the ADM TOGAF.

Some authors argue (Vorisek et al. 2011) that additional architecture has to be added into the concept – the architecture of ICT services. Vorisek et al. in (2011) propose to insert the ICT service architecture between phases B and C of ADM. In their SPSPR framework, the ICT service architecture involves all ICT services delivered to users and their links. The application and technology architectures involve only those software and hardware objects which are owned and administrated by the enterprise. They do not involve objects owned by the external service provider.

4 Software Life Cycle Processes for Very Small Entities

Worldwide-conducted surveys (Laporte et al. 2006; Anacleto et al. 2004) indicated that even though very small companies developing software have a significant influence on the economy, most of them do not implement any international standards and models like ISO/IEC12207 (ISO/IEC 12207: 2008) or CMMI. Subsequently, these companies have no or very limited opportunities to be recognised as entities that produce quality software and therefore are often cut off from contracts.

The ISO/IEC 29110 standard “Lifecycle Profiles for Very Small Entities” aims at addressing these issues. The term “very small entity” (VSE) was defined by the ISO/IEC JTC1/SC7 Working Group 24 and consequently adopted for use in the emerging ISO/IEC 29110 software process lifecycle standard (ISO/IEC 29110-1: 2010), as being “an entity (enterprise, organization, department or project) having up to 25 people”. The 29110 standard consists of five parts as shown in Fig. 20.3 (ISO/IEC 29110-1: 2010).

Fig. 20.3
figure 00203

ISO/IEC 29110 set of documents (ISO/IEC 29110-1: 2010)

Full size image

Part 1 Overview (ISO/IEC 29110-1) explains main concepts, terms and structure of the standard. Part 2 Framework and Taxonomy (ISO/IEC 29110-2) presents principles and mechanism of building VSE profiles.Footnote 1 Part 3 Assessment Guide (ISO/IEC 29110-3) defines the process assessment guidelines and compliance requirements needed to meet the purpose of the defined VSE profiles. This part of the standard is used by certified assessors for VSE assessment. Part 4 Specifications of VSE profiles (ISO/IEC 29110-4) provides the mapping to the source standards and is useful for method developers and assessors. Part 5 Management and Engineering Guide (ISO/IEC 29110-5) is intended for VSEs.

The set of 29110 standards was published in 2010. Part 1, 3 and 5 will be available at no cost from ISO. ISO/IEC 29110 is based on existing standards like ISO/IEC 12207 (2008), ISO/IEC 15289 (2006), ISO/IEC 15504 (2004) and ISO 9001 (2008). The approach used to develop ISO/IEC 29110 consists according to (O’Connor and Laporte 2010) of three steps: (1) selecting ISO/IEC 12207 process subset applicable to VSEs of less than 25 employees, (2) tailoring the subset to fit VSE needs, and (3) developing guidelines for VSEs.

A key concept of the ISO/IEC 29110 standard lies in development of various VSE profiles. As a starting point, the “Generic” profile group was defined, which is applicable to a vast majority of VSEs that do not develop critical software. Within the Generic Profile Group, four profiles were proposed, that is, Entry, Basic, Intermediate and Advanced. By using these profiles, very small companies have the chance to improve their processes in a clear and stepwise manner. At present, the Basic Profile intended for a single project with no special risks or situational factors was developed and published (at the end of 2010). Implementation of the Basic Profile enables VSE to establish good practices in the project management process (project planning, monitoring and control, configuration management) and in the software engineering process (requirements management, analysis, design, construction, verification, validation and testing). As some pilot projects of the Basic Profile implementation in VSEs showed, this profile is still difficult to implement for some companies. That is why the Entry Profile was proposed. The Intermediate Profile is on the contrary intended for VSE, which has more than one project at a time, and therefore is aware of assigning project resources, monitoring projects for achieving business objectives and customer satisfaction and defining, deploying and improving the organisational standard processes to achieve similar results in all projects. In addition, the Advanced Profile is going to support VSEs with business management practices.

To help VSE with implementation of the Basic Profile, series of deployment packages were developed and offered for free (Deployment packages repository). A Deployment Package acts as a detailed methodology that guides company through the process of profile implementation. Typical Deployment Package includes process descriptions, activities, tasks, roles and products, templates, checklists, examples, reference and mapping to standards and models and a list of supporting tools. In order to accelerate the adoption of the ISO/IEC 29110 standard, a set of university courses for undergraduate and graduate students was created (VSE Education Special Interest Group).

5 Combination of Software Process Improvement and Enterprise Architecture Initiatives

Despite a general experience that enterprise architecture is applied mostly by large companies, results of our survey (described in Sect. 2) show that it is also subject of an interest for small and medium enterprises (SMEs). EA is able to bring them business agility, efficiency and competitiveness, which are crucial for them. If an SME accepts the idea that EA could be beneficial, it primarily has to select a suitable EA framework. In this matter, I would recommend choosing the TOGAF framework. This conviction is derived from my experience in building framework for software development methodologies selection, my participation in development of standards for VSEs and analysis of various EA frameworks. TOGAF framework represents from my point of view the best option because of the following reasons:

  • TOGAF is the most used framework worldwide.

  • TOGAF may be used freely.

  • TOGAF is prepared for tailoring.

  • TOGAF embraces terminology of ISO/IEC 42010:2007 standard, so it can be combined with ISO/IEC 29110.

Despite the fact that using EA framework helps the company significantly, it is a resource-consuming process. According to (Ernst 2008), additional problems with EA implementation are stated, for example, “lack of an actual starting point for an EA management initiative, assumption that EA is introduced as one single piece and thereby lack of an incremental EA development”. In order to use the EA framework more effectively, it should be extended. To do so, it is essential to take into account that EA is not standalone in an organisation, but has to correlate with other existing frameworks or methods. Examples of these relationships, which are mentioned in TOGAF, are shown in Fig. 20.4. Regarding this chapter’s perspective, we focus on relationship between EA framework and Solution Development Methods. We have to control both sides of this relationship which are described in following sections.

Fig. 20.4
figure 00204

Management frameworks to co-ordinate with TOGAF (TOGAF – The Open Group Architecture Framework)

Full size image

5.1 Defining EA Framework for SMEs

EA framework can be improved by adding certain concepts, processes and features from Solution Development Methods which are much more mature. Therefore, we have recently proposed the enterprise architecture for small and medium enterprises (EAFSME) framework which takes an inspiration from the ISO/IEC 29110 standard “Lifecycle Profiles for Very Small Entities”.

EAFSME is based on TOGAF, but uses a subset of TOGAF practices that are suitable for small and medium companies. Moreover, a set of profiles is planned to be defined, that is, Entry, Basic, Intermediate and Advanced that will drive a company stepwise to the fulfilment of its goal – the EA implementation.

EAFSME aims to eliminate further limitations of TOGAF which were pointed out by Temnenco in (2007). He states that “TOGAF ADM is not an end-to-end process and requires organization-specific tailoring, as well TOGAF is not as detailed as some other methodologies and does not include any management tools like for example Rational Method Composer for RUP” (Temnenco 2007). To address this issue, we suppose to build up EAFSME profiles in the Eclipse Process Framework Composer that is available under the open-source licence and is also used for capturing VSE profiles. As stated earlier, small companies need detailed guidelines to be able to implement software process standards. This condition applies to EA implementation as well. Therefore, we are planning to develop Deployment Packages to capture detailed activities, roles and work products, as well as templates and checklists.

Extent of the adoption of enterprise architecture depends significantly on enterprise architect competencies. Our team at the Department of Information Technologies of Prague University of Economics carried out a research on the ways of reaction that universities apply in relation to competency requirements of enterprise architects (Gala and Jandos 2010). The results show that university courses provide only a partial knowledge for the enterprise architect’s profession. Therefore, a greater effort must be made to prepare undergraduate and graduate courses concentrated on building enterprise architect skills.

A support of architectural modelling constitutes another important condition for effective enterprise architecture adoption. A modelling tool must support both organisation-level and project-level models with full traceability between them; offer a wide range of models, such as the UML, database models, business-process models; and support version control and configuration management of the models (Temnenco 2007).

5.2 Mapping of ISO/IEC 29110 Standard to Enterprise Architecture

On the side of Solution Development Methods, it is worth taking into account the relationship to EA as well. It is a great opportunity to map the ISO/IEC 29110 standard for very small entities to EA as I am a member of the working group WG24 which develops this standard. In these days, we are working on the Intermediate and Advanced Profiles where relationship to EA is significant. Within WG24, I am going to propose to describe the relationship to EA, map VSE profiles to EA frameworks and develop a roadmap for VSEs showing how to build EA by implementing software process standards. Following this procedure, that is, first implement software process methods or standards and then enterprise architecture is recommended, and as Temnenco shows, “organizations routinely using project management and software lifecycle methodologies, such as PMBOK, RUP, Scrum are typically more successful at implementing Enterprise Architecture” (Temnenco 2007).

6 Conclusions

In this chapter, enterprise architecture and software process improvement initiatives were presented as an instrument capable of bringing business benefits to small and medium companies. More importantly, utilisation of synergy of both approaches was proposed. On the side of EA, the enterprise architecture for small and medium enterprises (EAFSME) framework was presented. On the side of software process improvement, a need of mapping Intermediate and Advanced Profiles for VSEs to EA was proposed. However, there is now a lot of work to be completed such as development of EAFSME profiles and their implementation in the Eclipse Process Framework Composer and also development of Deployment Packages.