"AFramework for Agile Enterprise Architecutre "
International Journal of Intelligent Information Technology Application, 2009, 2(4):182-186 A Framework for Agile Enterprise Architecture H. M. Shirazi Malek-Ashtar University of Technology/Faculty of ICT, Tehran, Iran firstname.lastname@example.org B. D. Rouhani and M. M. Shirazi Tehran University/Department of Computer, Tehran, Iran email@example.com Abstract— All enterprises require enterprise architecture in one another. These views include both business-oriented order to use its benefits but it is crucial for this project to be perspectives as well as technical perspectives. In many applied by formal stakeholders' satisfaction. A suitable ways enterprise architecture models are a communication framework for the enterprise requirements can be planned by bridge between senior business stakeholders and senior IT use of agile methods and its practices, in which we cannot only professionals. increase the percentage of prosperity but also we can return the asset to stakeholders as soon as possible. We put our whole Unfortunately, within the IT industry the terminology isn’t creativity in which makes it to be better. As applying the used in quite this way. Sometimes we use the term framework, some continual reviews will correct activities.By “Enterprise Architecture (EA)” to refer to the group of the use of this framework the risk of the project can be people responsible for modeling and then documenting the reduced and also the simultaneous cooperation of enterprise architecture. Other times we use the term to denote the architecture and project team is a reliable guarantee for process of doing this work. More commonly we are prosperity. Then holding variety meetings among stakeholders referring to the models, documents, and reusable items and presenting the rudimentary models and at last accepting of (components, frameworks, object, and so on) that reflect the them by the stakeholder cause our framework to proceed in a reliable way. Besides all of the stakeholders' viewpoints are put actual architecture ,. in the architecture, so in this way all of their needs are EA framework is like a pattern which is useful for provided. Another point is that several educational classes will thinking and explaining variety aspects of an enterprise be held during its implementation for people involved in, so which usually consists of models, diagrams and defined that the essential statement is taught to them and they can use it wherever is necessary. One of the other benefits of this products for this project. framework is to use a repository in order to keep information, The benefits of enterprise architecture can be summed up survey, adjust models and use of agile method in all steps of the using three words: better, faster, cheaper. It is important to framework. Finally it is vital to say that this framework is realize that the better, faster, cheaper (BFC) benefits come better, faster and cheaper than the classical one. at a price. You must be willing to invest in the underlying Index Terms— Agile, Enterprise Architecture, Framework organizational and cultural structures to support them. You I. INTRODUCTION need to recognize that these costs exist and ensure that the BFC benefits you achieve outweigh them. Better yet, adopt Agile Modeling’s principle Maximize Stakeholder ROI and Enterprise architecture(EA) consists of the various strive for maximal benefit . structures and processes of an organization. To complete this definition, an enterprise architecture model is a II. AGILE ENTERPRISE ARCHITECTURE representation of those structures and processes. A good enterprise architecture model will depict the organization When project teams work under the assumption that they both as it is today and as it is envisioned in the future, and can do anything that they want, that they can use any will map the various views representing the architecture to 182 1999-2459 /09/$25.00 ©2009 Engineering Technology Press technology that they want, chaos typically This framework can solve the deficiency and problems of results. Functionality and information will be duplicated classical practice and its framework also help enterprise and reuse will occur sporadically if at all. Systems will not achieve its goals fast because it has combined technical integrate well. Systems will conflict with one another and standards together so that it is basically agile. cause each other to fail. Costs will skyrocket because The framework consists of 7 models and 11 interactions similar products from different vendors, or even simply among them. Those models and interactions are made of different versions of the same product, will be purchased agile principles and values also they cover different and then operated within production. Although each viewpoints and aspects of project and enterprise. It surveys individual project may be very successful, as a portfolio 5 viewpoint and 6 enterprise aspects. they may have serious challenges. It doesn’t have to be this way . The viewpoints are: planer, owner, designer, builder and programmer. The cold reality is that very few software-based systems exist in a vacuum; instead they must co-exist with several Project aspects are: data, function, network, people, time and sometimes hundreds of other systems. Applications and motivation. must co-exist effectively with the other systems within your A. Four classes of requirements organization. Therefore an application must minimally be developed so that it doesn’t cause adverse affects on your The deliverable that represents the requirements must other systems and ideally it should be built to take take into account 4 classes of requirements that apply advantage of and to enhance a shared infrastructure. Every themselves to the following 4 levels of concern: strategy system must be built so it can fit into your existing and implementation constraints, functional, technological environment, better yet so that it reflects the future vision and organizational . for your organization. This sort of information should be captured in your enterprise architecture, in current state and future state models respectively. The goal for agile Level of Determines Correspondence in terms of enterprise architects is to ensure that this happens in an concern formalization effective manner, to ensure that the needs of the business stakeholders are understood and anticipated, and to support Strategy and Why Vision of the objectives and project teams in their development efforts ,. their priorities. Budget, delay, Constraints when quality and visibility risks and how many constraints. A. Challenges with Current Approaches These common problems are: Functional How Practical description of the -There isn’t an enterprise architecture effort. need in the form of requirements (functionalities, -Skewed focus. obligations and -Project teams don’t know the enterprise architecture exists. dependencies). -Project teams don’t follow the enterprise architecture. -Project teams don’t work with the enterprise architects. Technological With what Application of new -Outdated architecture. technologies to the solution (hardware and software). -Narrowly focused architecture models. -Dysfunctional “charge back” schemes. Organizational Who does it Impact on the organization -A “do all this extra work because it’s good for the and change accompaniment. company” attitude. A common thread behind these problems is a focus on processes and tools over individuals and interactions, the Table 1- level of concern exact opposite of the Agile Alliance’s first value. If organization experiences one or more of these problems then they may want to consider taking an agile approach to During working sessions targeting “immediate enterprise architecture . formalization and validation” of these requirements classes2, these are explored chronologically in the fundamental order III. THE AGILE FRAMEWORK described in table 1. On the other hand, all complexity relates to the operation as This framework is dynamic so that it can easily improve well as its pertinence rests in this principle, they must be project processes, IS and collaborate state. understood globally with concern for the immediate taking 183 into account of the interactions and dependencies they lead technologies for information processing and communication to. (NTIC), industrial data processing and the use of other forms of process automation) . B. Framework Models – Processes Operation Model: this domain covers primarily the rules applicable to operations composing current _ Business projection, resources and supporting processes and to the structure responsible for their execution. technologies model: this model plays the role of building These processes can be supported by automated systems the future system of operation. It integrates trend ("Information Systems and Technological Systems Model" information and the divergences arising from the "Technical domain) or they can be manually operated. and Functional Anticipation" and the "Process Monitoring and Continuous Optimization" models, in order to structure - Design Rudimentary model: designing a rudimentary by the future evolution of the company in terms of convergence using of prognosis's and viewpoints, presenting plans in the trajectories applying to: operational processes, human meeting in order to make them formal, sending plans to resources competencies, technological architecture and process operation models, and decreasing the project's risks. information system architecture. This plan is implemented by stakeholder's agreement. This model is used in order to make related future activities It is within this domain that company projects are situated. formal. Resource project prognosis's and protector This level is requested for utilizing systems again and again technological models are its input . The main benefit of this proposal framework is that it can support development system by available resources . C. Interaction between Models – Feedback on all of the functional or technical incidents – Technical and Functional Anticipation Model: the main noted at the time of Process operation. This flow is directed roles of this domain are: to anticipate which emergent towards the resources responsible for the corrective customer requirements or technologies are likely, in an maintenance of data processing and information systems for immediate future, to have an impact on the company; to immediate attention. The instrumentation is done through a feed this information to the "Business Projection, Resources light "anomaly correction" type of work-flow. and Supporting Technologies Model" domain. This domain – Feedback on functional divergences emerging between identifies stakeholders' concerns. This domain either can envisaged conditions and the real operating conditions of explain future enterprise view . the process, including volumetric evolution. This flow is – Process Monitoring and Continuous Optimization Model: directed towards the resources responsible for anticipating this domain is composed of the organizational structures and the evolution of the data processing and information it provides following facilities: to measure performance systems. Instrumentation recommended in the collaborative components, to detect possible divergences between space dedicated to rational Anticipation piloting. processes and the reality of operations. These organizational – Transfer via the rational Anticipation module of the structures have two principal missions: to improve or adjust information that is validated as representing a technical and the processes and to feed this information to the "Business functional tendency to be taken into account during the Projection, Resources and Supporting Technologies Model" development of future ISS. Support for this flow can be domain. implemented as a simple email warning refers to This model has agile adjustable structure so proposal information made available on the collaborative space framework can be adopted . dedicated to rational Anticipation piloting. – Adaptation of Competencies and Collaboration Types: – Change conduct and transfer upon materialization of the this domain covers the implementation of an agile information concerning operational competencies related to framework in terms of training and communication, offering the installation of the new production system. This flow is the following to Human Resources: improvement of their materialized as « job descriptions ». competencies, the conditions for their motivation, the – Upon Framing the architecture and operational constraints, appropriation of a collective intelligence. This framework transferring this Information happens in order to initiate the leads to the conditions required the "Process Monitoring and information processing systems update. Transfer of the Continuous Optimization Model" domain objective . applicative solution elements for integration tests at each – Information Systems and Technological Systems Model. release (Focus). This flow is materialized by the technical this domain covers the operation and control (standardized aspect in the Framing stage. ITIL, Cobit, and other models) of information and – Technical transition and installation of the new process technological systems (including, as usual, new version. 184 – Transition of organizational directives is related to the they are effectible to project due to make them more new process operation. This flow, emerging from a training enthusiastic to finish that project; so they support program, is materialized by instruction change. project teams entirely. – Real time fee back of incidents and operational • In this framework the architecture team and project divergences towards the Continuous process optimization teams have contemporary interactions and assistance, module in order to formalize an immediate corrective so this would ensure you about finishing the project, measure, then to initialize a procedure of corrective or and it is one of its benefits. To reach this goal, it is evolutionary maintenance. This flow is materialized by a documentary "Test" work-flow and/or a system of essential for all teams to continue their activities in a automated monitoring. same place and associate in order to have a single idea in the term of the activities they are doing. – Directives for the immediate correction of the manual part of the process if it is the case, or for temporary alternatives • Application of all of the ideas and viewpoints in the around the automated process. This flow is materialized by project and benefiting from creativity of those ideas. a corrective measure on operation instructions and possibly • Retrieving the processes and repeating the activities, leads to the allocation of new resources. correcting them due to finish that and finally - Sending prognoses and received resources and recognize the best and the final solution. technologies. • Exerting the agile methodology in producing in order to lessen the risk of the plan. - Transitioning of models, implementing that, monitoring its process and formalization. • Users of the plan should be taught in order to preventing all kind of invert of activities. 2 • Use of a repository in order to keep the information, survive and adjust the models. • Formalizing the results is another advantage of this plan. We can review the activities by presenting their Process 1 Business 3 Technical and Monitoring and Projection, Functional rudimentary models, so purvey the needs and apply Continuous Resource and Anticipation Optimization Supporting them; also we can assess the driven processes. It is Technologies essential to say that all of these activities are done with attendance of stakeholders and it causes their 10 4 adhesion. • Finally, the agile enterprise architecture of this Adaptation Of Design a framework cause that the enterprise to finish the competencies Rudimentary 9 8 and model architecture better, faster, cheaper and with the 5 Collaboration Types complete adhesion of stakeholders. The better result is that you can promote more in comparison with your rivals. 11 Processes Information Operation System and REFERENCES 7 Technological 6 System  ANSI/IEEE Std 1471-2000 Recommended Practice for Architectural Description,IEEE ,2000. Fig1- Agile Enterprise Architecture Framework (AEAF)  Scott W. Ambler "EUP , Enterprise Unified Process, Extending the Rational Unified Process", IV. CONCLUSION http://www.enterpriseunifiedprocess.com , 2006.  Schekkerman, Jaap, Enterprise Architecture Validation, The results of principles, models, interactions and August 2004. experiences achieved by this research are as follows:  Ambler, Scott W, “A Framework for Assessing and • This framework is performed in a way that can Improving Enterprise Architecture Management”, Agile Enterprise Architecture: Beyond , Enterprise Data change the stakeholder's supervision into sympathy Modeling, 2002. and cooperation so that it would make them feel that 185  AMBLER, SCOTT W, “AGILE ENTERPRISE ARCHITECTURE”,  Roel Wagter, Martin van den Berg, Joost Luijpers, AGILE ENTERPRISE ARCHITECTURE: BEYOND , Marlies van Steenbergen "Dynamic Enterprise Architecture, ENTERPRISE DATAMODELING, 2006. how to mark it work ", John Wiley & Sons, Inc, 2005.  Jean-Pierre Vickoff, " Architecture of a generation of high-performance enterprises"www.enterprise-agile.com Hossein M. Shirazi received his BSc degree in computer 2007. science from Mashhad University, Mashhad, Iran, in 1986,  Charles Edwards , Agile Enterprise Architecture - and the MSc and PhD degrees in computer engineering Integration to Projects 16th January 2007. from the University of New South Wales, Australia, in 1994  Charles Edwards, Agile Enterprise Architecture – Phases, and 1998, respectively. He is currently an associate Iterations & Disciplines , 20th Jan 2007. professor with the Faculty of Information and  Ambler, Scott W. Active Stakeholder Participation: An Communication Technology, University of Malek-Ashtar, Agile Best Practice, March 3, 2007. Iran. Dr Shirazi's research interests include Artificial  Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford, "Patterns of Intelligence, Expert Systems, Computer Security, Industrial Enterprise Application Architecture", Addison Wesley, Automation and the application of Fuzzy Logic, Neural 2002. Networks and Genetic Algorithms for modeling and control of dynamic systems. 186