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