From agile development to agile evolution of enterprise systems
•Télécharger en tant que PPT, PDF•
4 j'aime•1,474 vues
![Who am I? An enterprise solutions architect ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (6)
Similaire à From agile development to agile evolution of enterprise systems
Similaire à From agile development to agile evolution of enterprise systems (20)
Plus de Alexander SAMARIN
Plus de Alexander SAMARIN (20)
Dernier
Dernier (20)
From agile development to agile evolution of enterprise systems
- 1. From agile development to agile evolution of enterprise systems Dr Alexander Samarin www.samarin.biz Clio S.A. EuroPython conference 2006, CERN, Geneva, Switzerland
- 9. The main lesson from agile development: see and understand the big picture
- 14. Typical service and process oriented enterprise Business events : requests, payments, etc. Business processes Business events : offers, invoices, etc. Dept. Dept. Dept. Dept.
- 15. The simplified multi-layer model Execution Rules Objects Data repository repository repository repository
- 17. Works with other technologies Portal Grid infrastructure ESB infrastructure Business data services Business objects services Business rules services Business execution services Business measurement services Business intelligence services
- 19. A common tool with BPMN and BPEL (e.g. www.intalio.com)
- 41. Based on SOA: In general, a layer, a building block and a version of a building block are all services WSDL GUI (optional) Service logic Service database (optional) Other services (optional)
Notes de l'éditeur
- With a Ph.D. in information technology (IT), I have always worked in the provision of IT services. The posts that I have occupied have progressed through the phases of programmer, developer, business analyst, project manager to, most recently, enterprise solutions architect . Over the last several years, I successfully architected and delivered several IT solutions for different needs ranging from a heavy-duty production process to a federated distributed organization. I have innovated and employed an architectural framework for improving business process management systems. This framework is agile, service-oriented and provides for the integration of people, processes, systems and IT tools. Aiming towards achieving a good synergy between business needs and IT potentials, I have always managed to earn the respect and appreciation of users and clients. Skills and Experience Analysis and conceptual design of service-oriented architectures . A leadership role in the design and implementation of the automation of production business processes Experience in the design, implementation and maintenance of IT systems Successful use of the agile approach to software development . Strong leadership in the management of informal groups. Extensive experience with IT technologies Last position: " Chief Enterprise Solutions Architect " responsible for the architectural design, implementation, deployment and evolution of enterprise systems. The client base comprised international organizations, multinational and local companies, as well as public sector services in the French speaking part of Switzerland. Some work done: - development a ECM-based architecture for a private bank in Geneva (mainly for systems integration and business process automation), - demonstration of the Web Content Management solution for a public hospital, - preparation a proposal based on ECM products for a cantonal library, - implementing a working prototype of the document management for the ISO 9001 quality management system for an SME in Lausanne, - installation and evaluation of tools in a scope of a short-term contract with an international organization in Geneva for a pilot project on the archiving e-mails, and - discussing with several clients how ECM products and the “right” architecture can be used to transform their business operations to improve significantly their effectiveness and efficiency.
- The illustration is taken from the book “The innovator’s dilemma” Plone is a disruptive technological innovation Plone already delivers performance demanded at the low end of the market Assuming that Plone targets also the high end of the market Treat Plone as an “adult” on the ECM and BPM market and in the enterprise environment
- To automate and manage typical business procedures a multi-layer model has been used. Each layer is a level of abstraction of the business and addresses some particular concerns: The business data layer comprises information that is stored in existing repositories and traditional applications. The business objects layer comprises objects (actually, business data containers) specific for a particular business. The business regulations (and rules) layer comprises the actions on the business objects, which must be carried out to perform the business tasks. The business execution layer carries out the business procedures (each procedure is an orchestrated set of manual and automated tasks). The business modelling (and monitoring) layer analyses the business events, which summarize execution of the business procedures. The business intelligence layer implements enterprise-wide planning, performance evaluation and control actions applied to the business procedures. Each layer has some responsibilities; it uses the lower layer functionality, and it serves the higher layer. Each layer has a well-defined interface and its implementation is independent of that of others. Each layer comprises many building blocks that could be reused in different activities. Another practical observation is that different layers have life-cycles of different time scales: typical repositories have a 5-10 year life-span while the business requires continuous improvement. Because of the implementation independence of different layers, each layer may evolve at its own pace without being hampered by others. As a rule, the existing applications already implement many of business objects, relegations and events, but in a much unstructured way. The lasts are intermixed, not reusable and to be implemented again and again. This model is a tool which helps the organization to design system in business terms, but not in IT tools. Also, this model doesn't mandate to have all layers at the same time and to provide them in one project.
- This model is applied for both meta- and micro-projects. In an established architectural framework, we don’t actively involved into micro-projects. (if system works without you then you did a good job). But, it is critical to control evolution of the architectural framework itself.
- As the framework changes project management, two types of projects emerge; micro-projects for agile implementations of new features and meta-projects for framework maintenance and development. The latter resembles the Deming wheel: "plan" the feature(s) to be accomplished next as a micro-project according to results measurement and business priorities; "carry out" the changes; "validate" the changes; "analyse" the effect of the changes on the system and eventually propose unifications if, for example, a local modification was effective and should therefore be used to a wider extent. With a typical time per cycle per micro-project of 2 to 3 weeks, such project management is inherently different from the traditional multi year planning and the whole process becomes similar to maintenance rather than development. The descriptive below shows micro-projects mapped into phases of traditional IT projects. A note about timing – all values are real. They were achieved for automation of a production environment. Typical duration of a micro-project should correspond to a typical duration of related business. Typical timing of micro-projects: Definition phase: less than an hour. Specification / conception phases: one day Development / test / validation phases: from hours to days (depending on user’s availability). Deployment phase: practically instant. Definition phase: Business optimisation potential is evaluated. Features to be implemented are understood. Priorities and availability of features are communicated. Specification / conception phases: A product prototype using a workflow, an electronic form or a screen dump is used to validate what will be implemented. Missing components (if any) are identified and specified. Missing components (if any) are evaluated; use of new tools and/or utilities are justified. Development / test / validation phases: Missing components (if any) are incrementally developed, tested and validated. Complete product is assembled from existing and new components. The product is incrementally tested, validated and deployed. Extra monitoring, where necessary, is deployed. Resources requirements are estimated and the system is reconfigured to provide them. Production phase: The new product or latest version of the product is made available for use. In case of product or version replacement, verification of previous product retention cycle The documentation issue is addressed and simplified in several ways: Built-in document quality management system. Maximal use of visual tools (e.g. workflow, forms). User modifications are documented by the users IT-specific documentation is largely derived from the meta-project(s) and their adopted patterns. Programs, such as workflows, e-forms and schemas, work as documents and vice-versa.