what is technology architecture

What is Technology Architecture?

1

Copyright © 2008 Accenture All Rights Reserved. For Internal Use Only.

MTA 2010 What is Technology Architecture?

Internal Use Only

Hello. Welcome to this computer based training course, titled “What is Technology Architecture?”This is the first in a series of computer based and classroom training courses for technology architect practitioners across Accenture, aimed at providing us a common terminology, understanding of key concepts and considerations, and a consistent approach to the work we do in this space for our teams and our clients.


2

2Copyright © 2008 Accenture All Rights Reserved. For Internal Use Only.

Paul’s PerspectiveSI&T Leadership is committed to strengthening Architect development across the company, and the Master Technology Architect (MTA) Program is a key initiative underway to build architects with appropriate breadth and depth of specialization

The MTA CBTs are a key channel to deliver relevant architecture training, helping participants understand:– Areas of specialization that are important for

building breadth and depth of skills– Other principles and concepts to advance your

career as a Technology Architect

The Master Technology Architect Program is one of the most important initiatives that we’ve got underway in Technology Architecture right now. The goal of the MTA Program is to build appropriate depth as well as breadth of technology specialization and Architecture skills in our people. The CBTs are a very important ingredient in our MTA progression, because the CBTs really allow all of you to get both an overview of some of the areas of specialization that are important for you to understand, as well as to identify different areas where you can build your skills and get additional depth, either in our specialization areas or other Principles and Concepts that are important to advancing your career as a Technology Architect and pursuing advancement through the Master Technology Architect Program.


3


IntroductionIntended audience

Analyst through Consultant joining an Architecture teamNew joiners or anyone looking to get a general understanding of the terminology and structure of Technology Architecture efforts at AccenturePeople looking for a high-level overview of Accenture resources available to assist them in Technology Architecture work

Training environmentPresentation formatAudio transcripts are located in the slide notesPeriodic tests to reinforce key concepts

To advance to the next slide, click on the Play button at the bottom of the screen.

The intended audience for this course are people currently – or looking to be – staffed on Architecture teams. The word “Architecture” has different meanings across clients and settings, so this course is helpful for new Accenture joiners to understand what we mean when we discuss Architecture efforts and deliverables. In addition, this course refers to several other sources of content and provides a good introduction to the resources Accenture has available to assist Technical Architects and their teams.

This training uses a presentation style approach, with quizzes to occasionally check your knowledge.

Take some time to familiarize yourself with the screen components, like the playback control bar, the ability to view speaker notes during the playback of the presentation, as well as being able to increase the size of the screen. Use the search tab off to the left if you’d like to search any of the presentation’s content. Sites and materials presented here are linked to within course slides and are also available in the ‘ATTACHMENTS’ list from the top of the screen. In addition, a downloadable PDF version of this content is available to you from the ‘ATTACHMENTS’ list. At any point during the playback of the course, you can click on ‘SCREEN COMPONENTS OVERVIEW’ from the top of the screen to pause the presentation and learn about the player’s screen components. A glossary of terminology used in the course is available at the top of the player window as well. Once you have familiarized yourself with these and are ready to continue, please click the Play button at the bottom of the screen.


4


Learning ObjectivesLearning Objectives

Upon completing this course, you will be able to:– Describe where and how Architecture fits into work at Accenture,

and the deliverables Architecture teams are responsible for– Understand there are key considerations and trade-offs Technical

Architects must account for– Describe what makes a good architecture– Navigate to the various resources available to assist you in

completing Technology Architecture work

Upon completing this course, you will be able to describe: where and how Architecture fits into overall project work at Accenture, and the deliverables for which Architecture teams are responsible. You will be able to understand that there are key considerations and trade-offs Technical Architects must account for in their work. You will be able to describe what makes a good architecture. And last, you will learn where to access the various resources available to assist you in completing Technology Architecture work.


5


Agenda (Architecture Defined)

Architecture Defined

Where Technology Architecture Fits In

Technology Architecture Examples

Architecture Concerns

Architecture Methods and Frameworks

Here is the course agenda. To begin, let’s ground on terminology. The next slide contains a brief video describing architecture, employing the frequently used analogy of building a house.


6


What is Architecture?

What is Architecture, and what is its value? When you first hear the word Architecture, you might visualize a bridge, a building, or a house. But Architecture is much more than an object. It provides value by helping us break down complex problems. Here is an example. The architect works with a customer to determine the requirements. Based on the requirements, he now has a vision of the high-level components that he will use to develop the blueprints. Using the blueprints, the Architect will communicate to the builder how to build the structure. The builder will then work with various teams of contractors to complete specific aspects of the building.


7


Architecture DefinedTechnology Architecture provides the blueprint for the overall solution.

It defines the organizing structure of a system, comprised of: – The building blocks of the system – Their externally visible properties– Their relationships to each other

It ensures requirements are met in the overall solution– The building blocks work together effectively to address needs– Current business needs must be handled, with an eye towards the

future

It provides a common language and approach for teams– Enables reuse and standard approaches to addressing needs

In short, Architecture provides the blueprint for solutions. It is the concept of decomposing and organizing a system into parts that comprise the solution, and communicating that structure to the teams involved in building and supporting it. Through the architecture blueprint, everyone involved in the project can better understand where and how their piece fits into the larger system, what capability their part must deliver to others, as well as what capabilities they should leverage from other parts of the system.

The primary goal of Architecture is to ensure that the solution addresses current business needs elegantly and effectively, but with an eye towards the future. By describing how the building blocks fit together, an architecture defines the “landing spot” for requirements. Note that there are requirements—sometimes called aspects—that cut across entire systems. For example, performance or throughput requirements, and data security needs often encompass whole systems, and shape how they are designed and implemented. The architecture of a system provides approaches to address these cross-cutting requirements.

Last, Architecture helps project teams speak “a common language” and use consistent approaches when developing systems.


8


9


Agenda (Where Technology Architecture Fits In)






Now that we’ve covered the high-level definition of Architecture, let’s focus on where Technology Architecture fits into that broader picture.


10


Accenture Delivery ArchitecturesThe Accenture Delivery Architectures website contains this blueprint that depicts how application styles, delivery architectures, and domains relate.

It can be found at this address: http://architecture.accenture.com

Here you can see the starting view from the Accenture Delivery Architectures (ADA) site. This cube shows how Delivery Architectures, Application Styles, and Architecture Domains relate. The ADA site at http://architecture.accenture.com explains this blueprint in detail, and provides standard architecture frameworks and patterns, organized by application style. It also serves as a launching point into communications and forums for Accenture practitioners to develop and extend our architecture knowledge capital and assets. Note that ADA is a part of the overall Accenture Delivery Suite, which provides methods, tools, and metrics in addition to these architectures. Let’s quickly review what each face of the cube represents. We’ll go through them in more detail shortly. The front face is the delivery architecture, which you can see includes the infrastructure, technical and application architectures, as well as the applications that are delivered on those architectures for our projects. This is the Technology Architecture, and the focus of this CBT. Based on the functional and technical context of a given system, the delivery architectures generally follow standard designs and approaches. ADA groups these into what we call Application Styles, represented across the top face of the cube. Application Styles influence all the layers of the Delivery Architectures on the front face. The third face of the ADA cube contains Architecture Domains, which represent technical concepts that need to be considered by each Application Style and may have impact upon the Delivery Architecture.


11


ADA – Technology ArchitectureTechnology Architecture encompasses the layers shown on the front face of the ADA cube, and provides the foundation for applications to be built.

The layering represents how the architectures build upon each other to provide a solution.

Technology Architecture also defines the environments that build, execute, and operate a system.

Technology Architecture provides the foundation for applications to be built, and is represented here on the front face of the cube, in the layers labeled Application Architecture, Technical Architecture, and Infrastructure Architecture. The systems we create for our clients are composed of the Technology Architecture layers together with the applications that plug into them and provide business value.The layering shown is important: each layer builds upon the layers below it. Applications, at the top, fit into the structure provided by the application architecture and use common application services, such as data access and session management facilities. The application architecture layer, in turn, leverages common technical services provided by the technical architecture (for example, data caching and authentication). The technical architecture also defines how services are packaged into environments, to support development, execution, and operations of a system. All of the layers above, including the environments in which they run, reside on the platforms and technologies defined by the Infrastructure Architecture.


12


Technology ArchitectureExample

Click Play above to start the video

Let’s step back to our house analogy for a moment. This video shows how technology architectures fit together to create a solution.Click Play to start the video. With our house example, the overall structure would represent the complete solution. The application portion of the solution are the rooms, decorated and furnished appropriate to the functions they support, like beds in a bedroom. The application architecture would be concerned with how the functions of the rooms work together (for example, a single bathroom being shared by multiple bedrooms or a hallway acting as the entry from the garage into the house). The use of the space in the house is defined by the application architecture. The technical architecture is concerned with the supporting components to those functional spaces, and include items like the heating, cooling, electricity/gas, as well as structural framing elements like beams/trusses that are shared by the rooms within the house. Not depicted here, but equally important, is the infrastructure architecture. In this analogy, that would include items that supply needed services to which the house is connected in order to be useful, like the phone network, water and sewage lines, and the electrical grid.


13


Technology ArchitectureApplication Architecture

Applications Contain specific logic to support business processes. Can be custom-built or packaged. Adhere to a consistent style / structure, and use common services provided by the application architecture.

Application Architecture Consists of functional services/components that are common to multiple applications. Provides the underlying framework defining how functionality is partitioned and pieces interact. Supports standardization and reuse with common services. Application Services call services in the technical architecture to complete their work.

Since it is comprised of several layers, let’s examine technology architecture in more detail.Application architecture defines what the application components are, how they are arranged, and

how they work together. Well architected systems define the roles and responsibilities of the layers very clearly, and ensure that the boundaries of the layers meet without gaps or overlaps. In other words, application developers have a standard, well-understood set of components and services to extend from and leverage when they design and build the application.

The Application Architecture—highlighted here—defines the blueprints, patterns / frameworks, and supporting practices to organize the application in a consistent manner. The application layer at the top should essentially “plug in” to the structure of the application architecture below it. Different types of systems follow different structures, and this is where Application Styles fit in. Application Styles provide a standard Application Framework diagram and an Interactions and Services diagram that identifies the set of services to be provided by application architectures of a particular style. Examples of patterns and frameworks that fit into the application architecture layer include software design patterns like Singleton and Factory approaches to object creation, as well as frameworks like .NET and Java EE that specify how systems should be logically and physically partitioned. The Application Architecture also provides standard application services, enabling reuse and consistency across the enterprise. Sample application architecture services include Data Access layers, Logging / Audit trailing, and Transaction Management.


14


Technology ArchitectureTechnical Architecture

Technical ArchitectureA collection of services providing technical functionality, and is divided into Development, Execution, and Operations Environments.– The Development Environment

builds the Execution and the Operations Environments.

– The Execution Environment provides runtime services to the Development and the Operations Environments.

– The Operations Environment manages the Development and the Execution Environments.

Technical Architecture defines the middleware, technical services and system software required to support one or more application styles. Traditionally, it has been decomposed into Development, Execution, and Operations environments. Each of these environments interacts with the others, and also span the four layers you see here.

The Development Environment builds and maintains the Execution and the Operations Environments through a unified collection of technology services, tools, techniques, and standards. It includes items such as integrated development environments, source control tools, and build / test processes and tools.

The Execution Environment provides services to the Development and the Operations Environments, and is a unified collection of run-time technology services, control structures, and supporting infrastructure upon which application software runs. Examples of Execution Environment services include: message routing, message transformation, and data replication/synchronization.

The Operations Environment manages the Development and the Execution Environments, and consists of a unified collection of technology services, tools, standards and controls required to keep a production or Development Environment operating at the designed service level. It includes items like performance / usage monitoring, and network management.


15


Technology ArchitectureInfrastructure Architecture

Infrastructure ArchitectureThis architecture defines the hardware, networks, and system software that support the applications and business systems of an enterprise. It has four main capability areas:– Infrastructure Services provides data

management, channel, environment, and communication services.

– Infrastructure Platform provides the physical platform, operating system and network services for the system.

– Infrastructure Security Services is used to secure the enterprise network and the information being transported between physical endpoints.

– Performance and Availability helps to increase system responsiveness and up-time.

Infrastructure Architecture defines the hardware, networks, and system software that support the applications and business systems of an enterprise. It is broken down into four main capability areas.

The first area—Infrastructure Services—provides data management, channel, environment, and communication services. For example, DNS/DHCP services as well as VoIP services are provided in this area.

These services execute on the second capability area—Infrastructure Platform—which provides the physical platform, operating system and network services for the enterprise. This includes hardware like server blades and racks, in addition to system software to run network devices.

The third and fourth capability areas are not depicted here, because they relate directly to Architecture Domains, which are the cross cutting concerns that are captured on the third face of the ADA cube, which we’ll discuss shortly.

They span the first two capability areas shown here: Infrastructure Security Services are used to secure the enterprise network and the information being transported between physical endpoints. Encryption packages and Intrusion detection/response are services in this third area. The fourth and final area—Performance and Availability—helps to increase system responsiveness and up-time. Network load balancing is a good example of a service in this area comprised of both infrastructure services and platform elements.


16


ADA – Application StylesApplication Styles in the ADA cube provide an entry point to specific versions of one or more of the following, geared toward particular types of solutions:

Application FrameworksApplication architecture patterns,blueprints, and practices Technical Architectures

– Development environments– Execution environments

Infrastructure Architectures.

Moving from the front to the top face/dimension of the ADA cube brings us to Application Styles. An application style provides a focused, prescriptive approach that defines how a particular type of business system is commonly structured. It groups related architectures, frameworks, patterns, blueprints, and practices together, along with tailored methods to build out systems of that style.Each Application Style accounts for the Architecture Domain elements represented along the side face of the ADA cube, and clearly defines Technology Architectures on the front face of the cube, prescribing the approaches (including processes and deliverables) and key considerations specific to that style at each of the layers, using frameworks, patterns, blueprints and practices. More importantly, Application Styles are the organizing entity for a number of Accelerators that Accenture has been investing in to more effectively standardize and industrialize the development work that we do.An Application Style Accelerator provides a tailored version of the methodology to more prescriptively support the development of systems of a particular type, with deliverable templates and examples, a defined deliverables lifecycle throughout the project, recommended tools to create those deliverables, and checklists/guides (referencing best practices, standards, guidelines, and patterns) to assist people in creating deliverables. In addition, they include a prototype / reference application that runs on a pre-defined, pre-configured Execution Environment built with a pre-defined and pre-configured Development Environment.Let’s review the range of Application Styles in ADA next.


17


ADA – Application Styles: Focus Areas

Application Styles address different focus areas.

• Device-based focused styles include: Mobility and Silent Commerce/RFID.

• Processing focused styles include: Batch and Online Transaction Processing (which includes Smart Client and Web based).

• Integration styles include: Application Integration, Portal, and Enterprise Content Management.

• Business process styles include: Business Intelligence and Process Orchestration.

See the following sites for more information:https://collaboration.accenture.com/display/ADA/Application+Styles

https://collaboration.accenture.com/display/ADSJ/Accelerators

There are many Application styles, and each addresses different focus areas. Note that more than one may apply to a given system. In ADA and on this slide, they are listed in alphabetical order; however, they can be grouped based on their area of focus. The Mobility and Silent Commerce Application Styles have a device-based focus, while Batch and Online Transaction Processing (OLTP), represented here in the Smart Client and Web based Styles, are geared towards a particular processing approach. Styles focused on integration include Portal, Enterprise Content Management, and Application Integration Styles. Last are Application Styles with a functional business capability focus; those are Business Intelligence and Process Orchestration.An overview of the ADA Application Styles is provided in another CBT referenced at the end of this course. In addition, detailed walkthroughs of individual Application Styles will also be available in separate CBTs. From an ADA perspective, go to the first link shown at the bottom of this slide for a description of each. Information on the Accelerators mentioned earlier can be found at the second link shown on the slide.


18


ADA – Architecture DomainsArchitecture Domains describe sets of non-functional requirements. These are typically supported by the frameworks and patterns provided within the Application Styles and by the services and environments defined within the Technology Architecture – the four layers shown on the front of the cube.

The third face/dimension of the ADA cube depicts the architecture domains, which represent the cross-cutting architecture concerns that are sometimes termed “non-functional requirements.” They must be considered throughout each application style and have impacts upon the Application itself, as well as the Application, Technical, and Infrastructure Architectures from which the system will be built, represented on the front face of the cube. Fitting into this dimension are quality attributes, which are sometimes referred to as the “-ilities” because they end in those syllables. They include items such as availability and maintainability. We’ll touch on these in a little more detail later.


19


ADA - Architecture Domains: Focus Areas

Architecture Domains are represented in these four areas within ADA. This list is not exhaustive; there are more cross-cutting concerns to consider as an architect.

• Performance and availability is a key area of focus; Accenture has an offering described here: https://technology.accenture.com/CSAPerformanceDiagnostic

• Accenture’s Information Management Services (AIMS) provides an integrated approach to deal effectively with large amounts of disparate data across its lifecycle. AIMS is described here: https://kx.accenture.com/Organizations/Pages/tech-informationmgmt.aspx

• The Security Domain provides common approaches, best practices, and patterns within each Application Style.

• SOA has broad impacts across Application Styles, and has common elements represented in the Architecture Domain. The starting point for SOA at Accenture is here: https://soa.accenture.com/

Within ADA, these four Architecture Domains are called out. However, they are representative of a more broad set of requirements that must be considered and accounted for by Technology Architects in our designs and implementations.

Performance and Availability is one of the most significant challenges facing our client teams and our clients in providing value to the business and justifying the time and expenses incurred for solutions. Accenture provides specific performance and availability services to our client teams as part of our work, or as part of new arrangements at our clients to address applications not meeting performance and availability requirements. ADA links to Accenture’s Performance Diagnostic offering, at the URL shown here: https://technology.accenture.com/CSAPerformanceDiagnostic

Accenture Information Management Services (AIMS) provides the necessary strategy and structure to ensure that data will be governed, viewed, managed, and stored as a seamless whole supporting the lifecycle of information from capture through to transformation. This approach goes well beyond the data warehousing, management and reporting activities that constitute "business intelligence" in the minds of many of our clients.

Like performance and information, security aspects span the entire ADA website, providing common approaches, best practices, and common patterns enabling application-level security through the blueprints and frameworks found within each of the Application Styles.

SOA (short for service oriented architecture) has been defined as a Architecture Domain instead of an Application Style because it has impacts across all application styles, each of which can be implemented in a service oriented manner. The impacts SOA has across all application styles are represented within the domain. The unique characteristics of the domain include governance, standards, and impacts/guidelines of consuming and exposing services. The SOA Domain also includes an Application Framework, Execution Services, Interactions and Services Diagram and Patterns that depict a service oriented architecture for all application styles. See https://soa.accenture.com/ .


20


21


Agenda (Technology Architecture Examples)






Now that we understand what Technology Architecture is, and how it fits into the broader picture, let’s review some examples of these architectures in practice.Let’s consider a typical Accenture project. Suppose we have been asked to create a new web site to support online merchandise browsing and ordering. There are a number of high level functional and technical requirements the system must address: for example, providing a view of catalog contents based on a user’s geographic location and preferences, or integrating with an existing payments and invoicing system already in production at the client. The architecture of the system will depict and describe how and where those capabilities will be handled.


22


Application ArchitectureApplication Framework

Yellow portions depict application codeBlue portions identify application architecture componentsGreen portions represent parts of the technical and infrastructure architectures


One of the first places to look in the ADA site is along the top face of the cube: the Application Styles. Reviewing the descriptions of those, and given that we are being asked to create a web-based, online transaction system, the Web-based Application Style is a good starting point.Here is a snapshot of the Application Framework for the Web-based Application Style. This diagram shows the general structure for a browser-based, Online Transaction Processing (OLTP) system. It divides the system into logical and physical tiers, and layers/organizes the components in alignment with industry best practices, based on our experience in building robust, maintainable systems. This diagram also illustrates where applications, application architecture, and technical architecture meet: the application portions of the system are represented in yellow boxes here. The blue boxes represent application architecture services. Note in this figure how there is a blue application architecture component at some of the tier partitions. For example, between the business tier and the data tier in this figure, there is an application architecture component in blue that shields application developers coding the yellow boxes to its left from the specific technical architecture services shown in green in the data tier to its right. This concept of partitioning layers and separating concerns is an important goal in architectures.The bottom half of the picture contains a collection of blue boxes that represent services that are spread across application architecture (like global navigation and pagination support) down to more generic common services that are provided in the technical architecture, like authorization and encryption. The green colored portions of the figure here include services provided out-of-the-box from .NET/Java EE Application Servers.In the ADA cube, this diagram corresponds to the Application Architecture on the front face; specifically, the Blueprints section within the Application Architecture layer.


23


Application ArchitectureInteraction and Services



Continuing with our example, we now have a high-level system decomposition identified, and an organizing framework in place based on the client’s functional and technical needs. At this point in the analysis phase, we need to understand what the client currently has in place and what can be reused for our needs. Key considerations are the functional and technical constraints that must be accounted for in our solution, such as a preferred application server platform or an enterprise standard security infrastructure. The Technology Architecture team needs to identify gaps that currently exist in meeting our requirements, and which missing services can be provided by commercial off the shelf packages.Suppose for our sample client we’ve selected a Java EE flavor based on the client’s existing systems and their skill set. Now, the application and technical architecture is starting to take more shape, in the form of an application flow diagram. This figure from ADA shows the interactions and services that are called by components of the system in order to respond to a user-generated request. This view expands upon the previous framework diagram, and helps us describe how data and work flows through the application and across interfaces into the application and technical architectures of the system.Within the presentation tier to the left in this figure, note how many of the application components in yellow are surrounded and supported by blue boxes representing application architecture services. Here you can see how application developers are shielded from technical complexity; they simply “fill in the blanks” with specifics to satisfy their business requirements, and leverage the structure provided by the application and technical architectures to complete the processing of a request.Like the application framework picture, this application flow diagram is a part of the Blueprints section of the Application Architecture layer within ADA.


24


Technical ArchitectureReference Model

In conjunction with the application architecture definition, the technical architecture is also being defined in parallel. Portions of the technical architecture are already being called out for the execution environment, in the Application Framework and Interaction and Services diagrams we just reviewed. For the technical architecture, the Technology Architecture team needs to understand the gaps between current technical capabilities and the functional, technical, and cross-cutting requirements the system needs to address. Some of the resulting requirements are being highlighted through the Application Architecture work.

ADA provides Architecture Reference Models that organize technical architecture capabilities into logical groupings that can assist in the identification of requirements and their solutions. The reference models do not define the “ideal” architecture, but rather an inventory of capabilities that can be provided by technical architectures. It is the Technology Architecture team’s job to identify the set of capabilities that are necessary to meet the stated and sometimes implied requirements from the business.

This figure shows the web-based reference model for the execution environment within the technical architecture, with some capabilities shaded blue to indicate they are required for a web-based solution. For our example client, we will review their specific requirements and highlight additional capabilities that need to be supported. For example, we know our client has millions of items in its product catalog, so Search will be an important capability for users to be able to find their products effectively; in addition, Pagination controls allowing users to navigate through search results—and the catalog itself—must be defined and supported. In addition to the execution environment, the Technology Architecture team needs to define how the system will be developed and operated. These definitions are captured in the Development and Operations Environment deliverables that—together with the Execution Environment—comprise the Technical Architecture for our client.


25


Technical ArchitectureExecution Environment

At this point, we have a logical view of the services to be provided by the technical and application architectures. Now, we need to show how those services are delivered through packaged and custom software, hardware, networks / protocols, using an execution architecture diagram like the figure here. This picture shows the separation of client and server platforms, the particular browser versions and operating systems on the client, the application server systems, the database management systems, content repositories and network protocols used to connect them. This view begins to bridge the application and infrastructure architectures together. All of the details provided in the application architecture diagrams are not represented here; however, the individual product versions and packaged components are called out, so everyone knows what is being deployed to a logical server.

Note again that we are showing only execution environment examples in this CBT for the sake of brevity. The operations and development environments also need to be designed in the same way to complete the Technical Architecture work for our client.


26


Infrastructure Architecture

This content is illustrative only, and comes from an ADM sample:

https://methodology.accenture.com/infrastructure/adm_templates_samples_plugin/guidances/examples/resources/DC251%20DCT%20Conceptual%20Design%20v1.doc

This content is illustrative only, and comes from an ADM sample:

https://methodology.accenture.com/infrastructure/adm_templates_samples_plugin/guidances/examples/resources/DC251%20DCT%20Conceptual%20Design%20v1.doc

During the course of defining the application and technical architectures, the underlying Infrastructure Architecture begins to take shape as well. Here are examples of a wide area network topology and hardware sizing guidelines that are documented to show how the system will be deployed into our client’s existing environments and data centers. When defining the infrastructure architecture, we are describing the specifications and layout of the mainframes, servers, desktops, handheld computing devices and the routers, hubs, and switches that allow them to talk to each other within the walls of our client’s facilities. Suppose we have a technical requirement that an external catalog content provider currently sends updates via FTP to our system, but will be launching a service-oriented update mechanism in the next twelve months. From an infrastructure perspective, we need to account for the existing FTP server and how it connects with our system, and account for hardware and software to support the new SOA-based integration solution when it is ready.


27


Agenda (Architecture Concerns)






To this point, we’ve discussed the definition and structure of technology architecture, and where it fits into our work. We also reviewed an example of the types of deliverables that get created by Technology Architecture teams. However, architecture in practice is rarely so straightforward. What is most challenging—and rewarding—about being a technology architect is the optimization of meeting requirements while building a robust, maintainable system as simply and elegantly as possible. In this section, we’ll touch on the concerns, guiding principles, and tradeoffs that architects must address in their work.


28



• Availability• Performance• Scalability

Architecture Concerns:The non-functional requirements that architects are responsible for recognizing, prioritizing, and delivering.

Sometimes referred to as the “-ilities”. Some are expressed in ADA along the “Architecture Domains” face of the cube. The most frequently seen ones include:

• Maintainability• Operability• Portability

Are addressed using Guiding Principles.

Because many concerns and their corresponding guiding principles are mutually exclusive, Technology Architects must carefully consider options and determine tradeoffs in designing solutions for clients.

Goal of Architecture:To facilitate the construction of a system that satisfies requirements effectively, efficiently, and robustly.

The goal of architecture is to facilitate the construction of a system that satisfies requirements effectively, efficiently, and robustly. To an end-user, this means the system is available whenever it is needed, and does what it needs to do in a predictable and reliable way. To a developer, it means the system is easy to understand and explain to teammates, it is straightforward to extend for new/changing requirements, and can be supported without undue effort. To an operations specialist, this means the system can be monitored easily, degrades predictably when outages occur, and can scale up and down as usage changes over time.

How does a system get to that point? Through the careful consideration and prioritization of non-functional requirements called architectural concerns. These are sometimes called the “-ilities”because they end in those syllables. Note that some of the “-ilities” are expressed in the Architecture Domains face of the ADA cube. These concerns are not typically discerned when performing a functional requirements analysis. They require the architect to lead their identification and analysis, which is a key factor in successful engagements, since these often have enormous impact on the complexity and delivery cost of a system.

Different clients have different prioritizations of these concerns, and the systems themselves have varying needs. Architecture concerns are typically addressed by establishing guiding principles for a system. However, many concerns and their guiding principles are mutually exclusive; this requires Technology Architects to carefully weigh options and determine appropriate tradeoffs for a particular system.


29


Architecture Concerns: Availability, Performance, and Scalability

Does the architecture support the required business functions when they areneeded, and at the frequency and volume anticipated?

AvailabilityDoes the architecture support the application’s up-time requirements? (e.g., running during normal business hours across multiple time zones, or with a % uptime)

PerformanceDoes the system achieve the throughput and response-time requirements of the business?

ScalabilityCan the system be reconfigured to meet changing business volumes?

Let’s review some of the more frequently encountered concerns; consider these as examples of what a Technology Architect would own for a system.Availability has become increasingly important in today’s systems. How does the architecture support the application for the required time? Is there regularly scheduled maintenance? How long can it be down before it impacts the business? This last question is important to show that requirements should be grounded in business needs. It is easy to over-engineer and drive up system costs when focusing too heavily on one particular attribute at the expense of others, and losing sight of the overall business value of the system. High availability requires redundancy, which will impact other concerns like affordability and operability.Performance is a quality attribute that measures the ability of a system to deliver benefits and to process business events within a specified time frame. Can I get the individual response times I need? What happens when the number of concurrent users spikes at intervals during the day/week? Does the required transactional volume fit on the selected platforms? Considerations and responsibilities for technology architects are to benchmark early against peak loads and worst-case configurations. In achieving the right balance, and not over-engineering, follow the 80:20 Rule – do the important things fast, not everything. Look to keep data as close as possible to where it is processed, which may involve data and process partitioning, and caching strategies. These, of course, add complexity to the system that must be factored in to trade-off decisions.Scalability addresses the requirement that a system can be easily sized to allow for changes in scale without significant disruption. Today, technical architects are being asked to more effectively leverage available computing capacity, using techniques such as multithreading, server virtualization, and grid computing to accommodate this need. Key considerations for scalability include: growth in data and transaction volumes, network traffic increases, numbers/locations of users, and distributed data/processing. Design decisions can prevent scaling (for example, the inability to partition tables, and application logic that cannot be modularized and distributed).


30


Architecture Concerns: Maintainability, Operability, and Portability

Will this architecture continue to drive more business value than it costs thebusiness to run it?

MaintainabilityCan the system be modified, corrected, and extended easily? Is the architecture layered and modular to enable easier maintenance?

OperabilityIs the system easily managed, monitored, and reconfigured?

PortabilityCan the application system be deployed on multiple platforms (e.g. supporting both UNIX and Windows platforms)?

Once delivered, a good architecture should provide an improvement, and not a burden, to the business and teams that maintain and support it. These three architectural concerns focus on post-delivery aspects that should be considered during design and development.Maintainability addresses requirements that the system can be adjusted and updated over time as business and technical needs dictate. Can the system be modified easily? Is the architecture layered, modular, and flexible? Does it provide for likely future extensions? Does the architecture separate data and processing? Key considerations include configuration management and application packaging, distribution of software updates, and separation of data and code, considering necessary data/parameter maintenance applications, where needed.Operability addresses requirements that the system and the technical architecture can be managed and monitored effectively. Does the system itself perform consistently and predictably? Is it easy to operate? Are the technologies proven? As systems grow in size and complexity, automation becomes important. If the resolution to a recurring problem is simple, predictable, and tedious, then automate it. If it requires thought, assign it out to operations support groups. Areas of focus for automation include error logging, exception handling, event monitoring and diagnosis, as well as set-up and tear-down tasks for environments. Portability addresses the concern that the architecture is not tied to its current environment and can be migrated to a new environment easily. Key considerations to enable portability include use of abstraction layers, separating business logic from the technical architecture, and the separation of data and processing. Data is volatile, processing should be stable; if it canchange, it should probably be data.


31


Architecture Guiding PrinciplesA number of architecture guiding principles can help to address architecturalconcerns. Here is a sample selection:

Architecture IsolationKeep business logic out of the technical architecture.ModularityGroup related functions together, and provide ideally one place for a specific type of function to be implemented.ExtensibilityProvide functional and technical approaches for future extension where necessary.EncapsulationAbstract functionality into layers, shielding complexity from developers in other layers.Use of Standards and APIsProvide for the improvement or replacement of portions of systems, with more potential packaged options.

How are Architectural Concerns addressed? Through proven techniques and approaches summarized as guiding principles. There are a wide range of guiding principles that could be covered; we’ll focus on a few of the key ones as an introduction in this course. There is a follow-on CBT that will cover Technology Architecture Principles in much greater depth.

The first principle is Architecture Isolation, which ensures that technology architecture contains only architecture logic. It makes sure that business logic is included in the business architecture but not in the technology architecture. Similarly, it ensures that data itself is not included in the technology architecture: the data architecture is, but the actual data is not.Modularity groups related functions together, provides common shared utilities, and shields most developers from complexity in other areas. Good modularity in a technical architecture can significantly aid in maintenance and future extension. It also supports code re-use, simplicity, testing, and interoperability.The next principle is Extensibility, which provides mechanisms to extend the system for the future. As an example, hooks are calls made to dummy procedures for later, unspecified use. In object-oriented systems, abstract base classes provide a similar mechanism. They allow additional functionality to be added quickly and consistently. Prudent use of these techniques provides a clean way of achieving extensibility by allowing functionality to be added without having to open up and modify working code.Encapsulation is the technique inherent in the design of most technical architectures, which package and “wrap” functionality into different layers. Each layer then provides a standard set of interfaces to the layers above it and below it. It’s a type of modularity that keeps most application developers from having to concern themselves with the “lower-level plumbing” of a system.Last, the Use of approved Standards and APIs aids in portability, as systems that align to industry standards are generally easier to have portions improved/replaced over time by newer, best-of-breed frameworks, libraries, and products.


32


Architecture TradeoffsTechnology Architects need to ensure that the architecture supports business andtechnical requirements, while also meeting architectural goals.

Tradeoffs are often necessary, since principles are sometimes mutually exclusive.

If the application requires high availability, compromises have to be made with respect to the cost and complexity/maintainability of the application.

Adding flexibility to an architecture increases complexity, and can affect performance: generally, the more “rich” the architectural services, the more difficult they are to understand, use/coordinate, and maintain. This can lead to much longer development and bugfix cycles over time.

Keeping a focus on balancing and optimizing delivery of these non-functionalrequirements are what differentiates an architect from a coder.

With all of these concerns and principles, it’s difficult for the technical architecture to adhere to all of them. That’s where the role of Architect comes in and provides value, by weighing options and determining the right balance across these competing requirements and principles to optimize the solution. This focus differentiates architects from pure “coders.”Let’s discuss a few examples of tradeoffs architects typically have to consider.

Increasingly, application systems require high availability, such as a 24x7 operating window for a web-facing portion of the system. This can have broad impacts on the system’s total cost of ownership, in terms of environments and maintenance, as well as operations support. Likewise, the desire to be flexible can sometimes lead to “over-architected” solutions, requiring levels of complexity in the design and implementation that lead to longer development times, increased defect rates, and negative impacts on performance.

Let’s explore a scenario from our sample retail client to highlight the thought process of an architect versus a coder. Suppose we have a new requirement to read configuration data to support new catalogs for the website. The coder’s solution is to add a new database table, write a query against it, and embed it in the catalog business service. The architect’s considerations leading to a solution include the following:

How does this impact my performance – do we need to cache the data?If we cache the data, do we need be able to refresh caches dynamically when they change? Does it change, if so

how often?How would we manage this cached data across machines in a highly-available environment?What’s the nature of the data? Are we talking name-value pairs, or is there a more complex relationship?How will this configuration data be maintained?Will there be more requirements like this? Can we make this service generic enough to support those likely

future extensions?Does the current execution stack already contain a service we can leverage? If so, can it be extend to support this requirement? If not, how can we make this new service generic and

extensible?Can we use an open-source solution and would the client be willing to explore those options?How do we automate the tests for this?

By asking questions like this, the Architect takes a more holistic view and helps make sure the competing requirements, guidelines, and concerns are optimized for the system.


33


34


Agenda (Architecture Methods and Frameworks)






So far, we’ve introduced the definition of architecture, where technology architecture fits into our work, and reviewed samples of deliverables that get created by Technology Architecture teams. We just completed a section on architecture concerns, guiding principles, and tradeoffs that must be factored into our work, and while we all understand that a good technical architecture is a balancing act, achieving one relies on previous experience. That’s where our methodology tools and architecture frameworks come in. Let’s explore them briefly now.


35


Technology Architecture Methods Overview

Sample ADM Methods that sharethis top-level view:

CustomOraclePackagedSAP

The Accenture Delivery Methods (ADM) ground on the same top-level view, shown on the upper left side here. As you can see, several different work streams run in parallel through the lifecycle of a project’s delivery. ADM condenses the bulk of a Technology Architect's scope into one stream called "Technical Architecture" highlighted here; however, a Technology Architect needs to be familiar with all of the content of a particular ADM methodology and how the architecture stream is impacted by—and how it impacts—the other streams.

The second picture here shows a general timeframe of stages by workstream. You can see that the stages of Analysis, Design, Build, and Test within the Technical Architecture workstream are generally completed prior to those stages in the other workstreams. This makes sense, because the structure and environments created within the Technology Architectures need to be in place for the remaining teams to complete their work. Technology Architects always need to stay a few steps ahead of the remainder of the project teams.


36


Technology Architecture Work stream in ADM

The Technical Architecture work stream in the Accenture Delivery Methods defines the activities, deliverables, and roles needed to identify and document technical requirements and the resulting technology architecture deliverables.

The resources available within the Accenture Delivery Suite, including the ADA site and Accenture Delivery Tools, provide resources to jump start Technology Architecture efforts depicted here.

The Accenture Delivery Methods contain a detailed description of the process, deliverables, and roles involved in completing technology architecture work on an Accenture project. We won’t go into detail on ADM in this course; another CBT will focus on the Technology Architecture workstream in ADM.

Note that within the Technical Architecture workstream are the definition, design, and implementation of the architectures and environments we’ve discussed in this course. In the planning stage, blueprints are drafted with the support of the ADA resources we reviewed earlier. In the Analyze stage, requirements drive the refinement and completion of the Application Architecture and Technical Architecture Specifications, which again leverage ADA content. In the Design and Build stages of a project, this workstream focuses on the selection, design, and implementation of the development, execution, and operations environments for the solution. The Accenture Delivery Tools portion of ADS can assist in this stage of the project lifecycle. Throughout the duration of the project, infrastructures are defined and supported for the technical architecture environments.

As a part of the Accenture Delivery Suite, ADM also contains key considerations, forums, best practices, and samples to help guide teams along the way. Working reference architectures and accelerators continue to evolve through the incubator process, so keep an eye on the ADS websites, and contribute to the discussions and knowledge capital housed within the suite.


37


Architecture FrameworksFrom ADM Technical Architecture workstream, conceptual ArchitectureFrameworks get instantiated. These correspond to the examples we’vereviewed so far.

Using these conceptual frameworks, software is developed usingimplementation Frameworks, such as .NET or Spring.

Technology Architects identify components from one or more frameworks tocreate a system-specific framework based on the requirements for a project.

An Architectural Framework is:– A conceptual structure used to frame the work about to be done– Used to help designers understand what components are required and how

they fit together– Derived from industry and global standards– Guided by the nature of the system; ADA Application Styles each have their

own “flavor”– A high-level architectural pattern. Software patterns typically manifest

themselves in lower-level designs.

As we just saw, ADM lays out the timing and process for creating Technology Architecture deliverables, and includes guidelines and considerations from a process perspective. For an implementation perspective, we go to the Architecture Frameworks in ADA, which capture a standard design/development approach to solving particular problems, and are derived from industry standards. As you saw in the example earlier, ADA contains key principles and conceptual architecture frameworks within each application style. Those frameworks define and shape the services that lie within the application and technical architectures for a project. This consistent approach to solving recurring problems defines a pattern. While there are higher-level architecture patterns expressed in the frameworks, typical software patterns named in reference books (like Singleton or Strategy) don’t show up here. They are identified and applied during the lower-level design activities.

The Technology Architecture team takes these frameworks and patterns to structure the analysis of complex problems and to bring clarity to a discussion. Most often, frameworks are realized as diagrams – a key skill for an architect is the ability to abstract the complexity of a system into an organized framework and to depict that as one or more diagrams that are then used to convince, advocate and achieve consensus.


38


Architecture Frameworks -Descriptions

Delivery Architectures include tools and processes to support the design and implementation of execution and operations environments.

Accenture has a set of pre-configured, pre-selected tools that integrate with ADM and ADS called Accenture Delivery Tools.

ADT is located at http://tools.accenture.com

Development Environment Framework - Accenture Delivery Tools (ADT)

Provides a combination of tools and support services to keep a production system functioning

Located on Accenture Delivery Architectures at https://collaboration.accenture.com/display/ADA/Operations+Architecture

Operations Environment Framework

Supports the common run-time services required when an application executes

Application Styles have specific frameworks. There is a generalreference model on the Accenture Delivery Architectures site at https://collaboration.accenture.com/display/ADA/Execution+Architecture

Execution Environment Frameworks

Remember that Technology Architecture includes several different environments that span Infrastructure, Technical, and Application Architectures. The Architecture Frameworks found within the Application Styles in ADA focus primarily on the Execution Environment, which are the common run-time services supporting an application. The other two environments listed here—the Operations and Development Environments—are not defined per Application Style.The Operations Environment provides the tools and services to keep a production system (an execution environment) running. That framework can be found in ADA at the link provided.The Development Environment includes the tools and processes to design, implement, and maintain the execution and operations environments. Accenture has a blueprint of preconfigured, integrated tools as a part of the Accenture Delivery Tools, found at http://tools.accenture.com.These frameworks can be used be used for several purposes: first, as a basis for an overall design; second, to provide a checklist of services to consider in clarifying a current operating environment (COE); and third, as a tool to identify preferred solutions through a standard operating environment (SOE).


39


Wrap-UpThis course provided an introduction to technology architecture, what it is and how it fits into the work we do. There is much more detail available on the topics covered here in the ‘ATTACHMENTS’ link.From this introductory course, there are several follow-on courses:– “Base knowledge” CBT courses

• Technology Architect Roles within Accenture• Technology Architecture Principles• Introduction to ADA

– “Required knowledge” courses• Introduction to Architecture Types, Application Styles, and Frameworks• Architecture Concepts and –Ilities• Architecture Delivery Environment Fundamentals

This concludes the course. We touched very briefly on many different topics in this introductory lesson, so be sure to visit the ‘ATTACHMENTS’ link at the top to explore areas in further detail.

Now proceed to the Final Assessment. You will need to answer all of the questions correctly to pass this Assessment. Once you pass the Assessment, mark yourself complete in myLearning to obtain credit for this course.


40

what is technology architecture

Documents

architecture skills

good architecture

architecture fits

word architecture

technology architect

relevant architecture

resources accenture

accenture people