Defining the Discipline of Application Architecture

Transcription

1 Research Publication Date: 12 June 2008 ID Number: G Defining the Discipline of Application Architecture Michael J. Blechar, Daniel Sholler, Anthony Bradley The term "application architecture" is commonly associated with various application design and architectural efforts that organizations often perform in an ad hoc or embedded manner that the new demands of Web-centric, interoperable, highly distributed systems have made separate and critical. Application architecture is a critical discipline for building effective application services and solutions that work with "common componentry" in a manner that satisfies the organization's requirements, while supporting its future evolution. It is nearly impossible to successfully build IT applications, or a portfolio of applications, without leveraging various patterns, practices and frameworks. Key Findings The increasing demand for application agility and shareability leading to and feeding off of service-oriented architecture (SOA) is driving complexity into application design. Application architects bring solution design knowledge, which enables more-traditional developers to transition to new application delivery types (such as service-oriented development), and less-skilled developers to become proficient in them more quickly. IT application and business process agility require well-designed and highly reusable software services that can be assembled as part of new solutions. Application architects are tasked with the design of these services. Recommendations Build a core competency in the application architecture discipline. Define and staff the role of application architect as part of executing SOA and business process management (BPM) projects. Application architects must work collaboratively with enterprise, technical, business and information architects as part of the organization's solution architecture efforts to ensure that the systems built conform to the requirements, principles and models that support the enterprise's change agenda, as captured in the gap plan and transition road map. Reproduction and distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartner's research may discuss legal issues related to the information technology business, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice.

2 TABLE OF CONTENTS Analysis Definition of Application Architecture Why Should I Care About Application Architecture? Putting Application Architecture in Context Scope of the Application Architect Role Examples of Architectural Decisions Made at Application Design Time What You Need to Know Recommended Reading LIST OF FIGURES Figure 1. Gartner's EA Framework... 6 Figure 2. The Application Architect Role at a Glance... 8 Publication Date: 12 June 2008/ID Number: G Page 2 of 11

3 ANALYSIS 1.0 Definition of Application Architecture Application architecture is the discipline of designing an IT material solution to an identified business need that incorporates situational guidelines and constraints (such as business requirements, enterprise architecture [EA], information architecture, existing infrastructure, available resources and the state of technology) to provide a core set of architecture artifacts that will guide subsequent application construction and deployment efforts. The complexities of today's IT solutions make application architectures a critical core-competency for any midsize to large company. Legacy application architectures must be understood and documented to improve the effective support of an asset and to lengthen its life. New applications will leverage newer architectural concepts, such as SOA and WOA, which must be combined with the legacy applications using older concepts. Organizations must understand how the existing models, design patterns, architectural styles and frameworks are evolving to make intelligent decisions about their own application architectures. Application architects must factor into the design of new applications and software services: The current application portfolio and short-term changes that are being made to it through build, buy and sourcing projects The longer-term future enterprise solution architecture plans as expressed and consolidated in the EA plan or road map The greater interoperability ecosystem in which the service or application must operate Industry and enterprise design standards Security, performance and costs related to application design choices The requirements, principles and models that support the enterprise's change agenda The trade-offs or conflicts that may emerge between short-term project needs and endstate enterprise architecture goals Application architects flesh out the architecture of a system through the use of design patterns (which they establish and evolve in cooperation with the broader IT architecture community). To improve application productivity, quality, consistency and compliancy, they are responsible for establishing, promoting and managing the reuse of application architecture practices and artifacts in support of the application portfolio as a whole. A primary mantra of application architecture is to leverage what has been built, and build what can be leveraged. This not only includes delivered services and applications, but also application architecture best practices and design artifacts. Example design artifacts include: Requirements decomposition Business use cases System use cases Reference architectures Logical architectures Publication Date: 12 June 2008/ID Number: G Page 3 of 11

4 Design patterns Sequence diagrams Event streams Information flows Information structures Service catalogs Service definitions Service documentation Testing guidelines Deployment patterns Deployment guidelines 2.0 Why Should I Care About Application Architecture? Application architecture success is determined by the level of effective sharing and execution of application architecture practices and artifacts resulting in design efforts that improve the agility (responsiveness to change) and cost-effectiveness of software applications. Direct application architecture benefits include, but are not limited to: better fulfillment of business needs, cost savings, easier system integration, faster application delivery, improved system performance, lower maintenance effort, and greater resilience and adaptability to change. In the move from a more insular and monolithic application delivery approach to an agile and leveraged interoperability ecosystem, application architects must pursue new approaches to application design, while maximizing the role of existing systems. This "current" base of systems will be extended by additional architectural overlays to support new approaches and application types, such as SOA, WOA, EDA, enterprise "mashups" and social applications. To successfully navigate to these new architectures, organizations must: Understand how these architectures fit into the enterprise and deliver value. Determine when it's best to use a specific architectural approach. Design software, data components and services to cross organizational and architectural boundaries. Design for end-to-end performance and cost-effective levels of consistency, reliability, performance and agility of application solutions across the enterprise. Leverage the expertise of architects in application design to make developers more productive and to reduce development cost and time. Design the application and, in aggregation, the application portfolio so they can evolve in response to business changes and EA planning. In moving to next-generation architectures, there are four major objectives for the application architecture discipline: Publication Date: 12 June 2008/ID Number: G Page 4 of 11

5 1. Design for leverage: Improve application leverage through the use of standards, a focus on interoperability and robust security mechanisms based on application architecture analysis and design best practices. 2. Design for evolveability: Ensure that a sound migration path exists from the current to the future versions of software architectures. 3. Design for simplicity: Enable less-skilled developers to create and maintain application solutions. Improve developer productivity and facilitate the speed of architectural and design changes to application solutions. 4. Design for serendipity: Serendipity is the pinnacle of flexibility. Application architecture should not only facilitate known flexibility needs, but should strive to enable emergence and innovation that is yet unknown. 3.0 Putting Application Architecture in Context As depicted in Figure 1, Gartner's EA framework contains three major "sub-architectures" business, information and technology. Enterprise architects work at a conceptual level to build future "enterprise solution architectures" based on business plans and strategies. For more information on the enterprise solution architecture, see "Gartner Enterprise Architecture Framework: Evolution 2005." The enterprise architects work with business, information, technical and application architects to plan and guide the transition from the current business processes, application portfolio, databases, platforms and technologies toward the future state. This transition planning usually takes the form of a gap plan or road map, which outlines the enterprise's evolution via the intended design of future enterprise solutions. The transition plans must cost-effectively balance current operational needs with the march toward the future state. An enterprise solution will consist of one or, more likely, many application solutions (among other things). Therefore, application architecture, which centers on designing material application solutions, is a critical part of enterprise solution architecture realization. Publication Date: 12 June 2008/ID Number: G Page 5 of 11

6 Figure 1. Gartner's EA Framework Solution Architecture Source: Gartner (June 2008) Application architecture has a fractal relationship to EA. It focuses on the architecture portion of the application solution (that is, the application solution architecture), which is a fractal subset of the enterprise solution architecture. It unifies relevant segments of the EA disciplines of enterprise information architecture, enterprise business architecture and enterprise technical architecture to address the needs of a particular application solution in a manner that is consistent with and adds value to the overall application portfolio. Application architects must be able to effectively collaborate with EAs to serve the broader and longer-term vision of the enterprise solution architecture, as well as the immediate needs of the target application solution. In other words, application architects ensure that applications work together for some broader business purpose in support of the organization's overarching strategies, rather than function as isolated islands of rigid and limited capability. For more information on the roles of the business and information architects, see "Q&A: Business Analyst and Business Architect Roles Are Different" and "Gartner Defines Enterprise Information Architecture." In organizations where a robust EA capability exists, the enterprise architects are responsible for the overall development and management of the future enterprise solution architecture. The enterprise architects provide the enterprise vision and constraints to the application, information, business and technical architects, and collaborate with them in developing the future enterprise solution architecture and in formulating application solution architectures facilitating the transition to it. As a result, in some organizations, the broader technical and standardization aspects of the application architecture role are fulfilled within the EA team (by enterprise architects, technical Publication Date: 12 June 2008/ID Number: G Page 6 of 11

7 architects or application architects attached to the EA team), while particular application solution architectures are done by application architects assigned to the application solution project team. Application architects participate as collaborative members of the EA team, as well as members of the project-specific application solution team. This cross-pollination, and hybrid alternatives, is an emerging best practice, and is successful as long as the application architect role is properly performed at both levels. For more information on the collaborative roles, see "Building the Enterprise Architecture Team." 4.0 Scope of the Application Architect Role As depicted in Figure 2, the application architect starts with two architecture givens the existing application portfolio within the current "as-is" application solution architecture and the future "tobe" enterprise solution architecture. The application architect establishes the design standards that are to be used when applications are built (and, ideally, to which application packages will adhere to if purchased). As application projects receive requirements from the business units, application architects decide which reusable design patterns and frameworks to apply to the projects. Application architects build the application design, including which existing software and data services will be assembled into the new application solutions. They also determine when departures to existing standard design artifacts are required for a particular application solution, and they progress through the architecture governance process to gain exception. This effort helps ensure that the architecture artifacts evolve with changing technology and application solution requirements. Publication Date: 12 June 2008/ID Number: G Page 7 of 11

8 Figure 2. The Application Architect Role at a Glance Current Application Architecture Work in Process Architecture No. 1 Work in Process Architecture No. 2 Future Solution Architecture Design Patterns & Frameworks Reusable Software Services Design Standards Reusable Data Services Work in Process Reqmts. No. 1 Application Design Work in Process Reqmts. No. 2 Source: Gartner (June 2008) The application architect establishes when and how legacy applications are to be wrapped or split apart as software services, and which new software services are to be developed. The application architect publishes design artifacts and assists the EA team, application portfolio managers and software service providers in promoting enterprise leverage of software services and design artifacts. All of this needs to be coordinated across releases of the application portfolio as part of the evolving "work in process" transition toward the enterprise solution architecture. At this juncture, application architects need to coordinate their efforts with others. For example, information architects will need to coordinate the master data management efforts, data services, and database designs and deployments in conjunction with application architects' software service designs. Additional details uncovered during requirements-gathering may cause enterprise architects to tweak the future solution architecture. Application architects must work closely with developers and package implementers to ensure design compliance and service reuse. Integration and technical architects must ensure that performance and security requirements can be met in terms of middleware, workflow, and orchestration software and networks. The application architect role can be implemented in many ways. In some organizations, the EA group may create a "solution architect" position to address the role of application architect. Publication Date: 12 June 2008/ID Number: G Page 8 of 11

9 Enterprises with smaller IT organizations may elect to have software engineers fill the role on a project-by-project basis. However, given the skill set and breadth of knowledge needed, we are increasingly seeing the role of application architect staffed as part of a center of excellence that includes support for SOA design, governance, service registries and repositories, and reuse metrics. These architects are often attached or assigned to application solution project teams. Regardless of how the application architect role is implemented, it is critical to the future success of applications, especially for SOA and BPM initiatives, because they hinge on the ability to design and deliver reusable services that can be assembled and executed effectively within a varied set of technical architecture topologies. Moreover, the application architect is needed to ensure a sound transition strategy from current application solution architectures to the future enterprise solution architecture. 5.0 Examples of Architectural Decisions Made at Application Design Time Many application architecture decisions need to be made at solution design time. There are several areas of solution design and architecture that overlap (for example, the creation of reusable services). The solution design will likely incorporate a set of potentially reusable services, some of which will be exposed to the user. For example, a CRM system may have a service that returns various statistics about the structure of sales territories. Because territories (in this particular example) are named accounts, and those are adjusted for work-balance regularly, this service information is volatile. Although it is clear that the provisioning of the information must be a service, what is not clear is how that information will be consumed. Depending on the consumption pattern, different architectural options are available. For example, if the principle consumers of this application were applications owned by the company that resided across different network topologies, technology platforms and security domains, then it is likely that the application architect would follow a path of using Web services or traditional middleware connectivity to enable application interactions with multihop complexities. However, if this information was primarily used by business analysts to determine the proper rebalancing of accounts and territories, and likely required some interpretation and possible combination with external data (such as map location), then the application architect might decide that the most useful method of access would be an enterprise mashup using WOA. There are other classes of decisions that are similar. For example, the application architecture team may have determined that using the Spring framework is an appropriate choice for Java development. However, formulating the policies for when to use Java Database Connectivity, data acquisitions or Java Persistence APIs to manage persistence is a specific design question for a particular application, and one that is made time and time again by designers. Therefore, the decision should be subject to some architectural policy established by the application architect to simplify the decision. In this way, the knowledge of the application architect can be leveraged by less-skilled developers. This is an example of the application architect constructing application development and deployment guidance. Other examples include details that will fundamentally shape the differences in design: Does the application require the use of message-oriented middleware, or do we rely on HTTP messaging or some other networking standards (such as raw Transmission Control Protocol [TCP])? Publication Date: 12 June 2008/ID Number: G Page 9 of 11

10 Given the expected service levels, does this program require us to run it on our commercial XTP application server environment (which happens to be WebSphere); and if so, should we program to the Spring/WebSphere integration model? Should the application use WOA or Web services? Does the need exist to control processing using context-driven architecture "environment-sensing" capabilities? 6.0 What You Need to Know As organizations evolve from mainframe and traditional client/server architectures to SOA and other new age and future architectures in the pursuit of increased developer productivity and enhanced application agility, they must pay greater attention to the discipline of application architecture. Therefore, ensuring that the role of application architect is properly fulfilled should be a priority. Because software developers generally lack the "bigger picture" systems design knowledge needed for the role of application architect, and most enterprise architects lack the technical ability to translate between business analysts and development teams to determine what constitutes good reusable services, organizations should staff the role with people that have a balanced mix of technical systems design, business requirements gathering and communication skills. Application architects help realize a smooth transition from the current application portfolio to the future enterprise solution architecture. Through the effective development, management and sharing of high-quality application design artifacts, they promote the development and management of leverageable application and information services that can be assembled and reassembled (that is, orchestrated) to flexibly address changing business process workflows. Consider the discipline of application architecture a key part of enabling the next generation of IT solutions in your organization. RECOMMENDED READING "Key Issues in Application Architecture, 2008" "Key Issues for SOA, EDA and WOA, 2008" "SOA Applications Should Mix Client/Server, EDA and Conversational Patterns" "Service-Oriented Architecture Overview and Guide to SOA Research" "Tutorial for EDA and How It Relates to SOA" "Key Issues for Enterprise 'Mashup' Practices, Technologies and Products, 2008" "Applying WS-* Based Web Services and WOA Standards to Enterprise Application-to- Application Interoperability Challenges" "Understanding and Applying the Design Differences Between WS-* Based Architecture and Web-Oriented Architecture" "Demand for SA Applications Drives EP Systems Enabled by SOA and Web 2.0 Synergy" Publication Date: 12 June 2008/ID Number: G Page 10 of 11

11 REGIONAL HEADQUARTERS Corporate Headquarters 56 Top Gallant Road Stamford, CT U.S.A European Headquarters Tamesis The Glanty Egham Surrey, TW20 9AW UNITED KINGDOM Asia/Pacific Headquarters Gartner Australasia Pty. Ltd. Level 9, 141 Walker Street North Sydney New South Wales 2060 AUSTRALIA Japan Headquarters Gartner Japan Ltd. Aobadai Hills, 6F 7-7, Aobadai, 4-chome Meguro-ku, Tokyo JAPAN Latin America Headquarters Gartner do Brazil Av. das Nações Unidas, andar World Trade Center São Paulo SP BRAZIL Publication Date: 12 June 2008/ID Number: G Page 11 of 11