Your SlideShare is downloading. ×
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Praxeme, the enterprise methodology 04/30/10
  • Praxeme, the enterprise methodology 04/30/10 Ce document est protégé par une licence « creative common ». Il peut être diffusé, reproduit, réutilisé, en tout ou en partie, à condition d’en citer l’origine et l’auteur. Les nouveaux matériaux produits doivent s’appliquer les mêmes conditions d’ouverture et de respect de la propriété intellectuelle.
  • Praxeme, la méthodologie d'entreprise 30/04/10
  • Praxeme, the enterprise methodology 04/30/10
  • AXA - Group Information System 30/04/10 [email_address]
  • AXA - Group Information System 30/04/10 [email_address]
  • AXA - Group Information System 30/04/10 [email_address] This spontaneous approach of business reality ranks among the functionalist approaches. It entails a difficulty: we are considering the enterprise in its organisational aspect. Yet, what we see in this aspect are actors, activities, processes, use-cases... All this stuff conveys organisational choices. Therefore, representations of this aspect can hardly be shared and generalized. When the purpose is convergence, simplification, agility... we need a more generic representation. We need to isolate the core business knowledge, using abstraction and expelling variability. We must recognise above this “pragmatic” (organizational) aspect a more abstract one, made of business objects, regardless of organisational habits and, of course, independent of technical choices. This aspect, we name it semantic. The semantic model is not only a sort of conceptual data model; it intends to express the business knowledge. We can use here an object oriented approach, which provides us with all the tools we need: class diagram to structure the concepts, state machines to catch the transformations and objects life cycles, Etc. Object oriented approach is connoted software but it lies upon philosophical works. That explains its ability to efficiently structure representations. It can really empower the formal expression of business knowledge.
  • AXA - Group Information System 30/04/10 [email_address] When equipped with the two business models – semantic and pragmatic – we can search for a better structure for the software solution. If we conceive this structure directly in terms of technology and technical choices, we will get a representation which will be subjected to technical change. Also, there will be a risk of entering in excruciating details. Such a representation will make it impossible to drive the IS transformation on the long term. For all these reasons, our frame introduces an intermediate aspect, between business and IT: the logical aspect. It is the ground where will be made the structural decisions regarding the software system. For instance, SOA is a style for a logical architecture. The logical aspect is linked with the previous aspects. The methodology states the derivation rules which help discovering the logical services.
  • AXA - Group Information System 30/04/10 [email_address] By applying this approach, we change deeply the structure of the system. Indeed, the logical architect receives from the semantic model a list of objects domains. Objects domains are an alternative way for structuring a model, opposed to functional domains. For more details, see the “Guide to logical aspect”.
  • Praxeme, the enterprise methodology 04/30/10
  • Praxeme, the enterprise methodology 04/30/10
  • Praxeme, the enterprise methodology 04/30/10
  • Praxeme, the enterprise methodology 04/30/10
  • Praxeme, the enterprise methodology 04/30/10
  • AXA - Group Information System 30/04/10 [email_address] Once the aspects have been identified, the question is: what kind of actors, roles, competencies… should we mobilize? A main measure consists in distinguishing between two disciplines of architecture, each of those requiring very different skills, knowledge and personalities: technical architecture and logical architecture. For every aspect, we can identify roles based on the same scheme: Architect: who makes the overall decision; Designer or Modeler: who digs into details; Expert: who brings the knowledge without necessary handling the formal expression nor the entire scope. … Praxeme, the enterprise methodology
  • AXA - Group Information System 30/04/10 [email_address]
  • AXA - Group Information System 30/04/10 [email_address]
  • Transcript

    • 1. Business Architecture
      • Position & methods
      2009-12-17 SY9-03 «  Theory without practice is useless; practice without theory is blind. » Immanuel Kant
    • 2. Presentation objective
      • Objective
      • Topics
        • Relation to the Enterprise Transformation Manifesto
        • Business architecture, business analysis
        • Enterprise architecture
        • Objectives, dictionaries, requirements…
      SY9-03 Introduce the discipline and summarize Praxeme contribution to it Duration: 1 h Document protection
    • 3. Agenda SY9-03 Q&R Partie Horaire Durée BA, a definition (DVAU) 15h30 30’ Place in a comprehensive approach (Fabien VILLARD) 16h 10’ Scoping or political aspect (Philippe DESFRAY) 16h10 20’
    • 4. Business Architecture, a definition
      • Terms
        • Business, Enterprise
        • Architecture, Analysis
      • Representation
        • What is it about?
      SY9-03 1
    • 5. “ Business”
      • The term “business” refers to the essential and operational activity of the enterprise
        • Especially when used as an adjective
        • As opposed to:
          • IT
          • Management
          • Strategy…
      • Proposed definition
        • “ The core reality of the enterprise, including its knowledge, how-how, activities, values, raisons d’être…”
    • 6. “ Analysis”
      • “ The detailed study or examination of something in order to understand more about it”
            • Source: Oxford Dictionary
      • “ Business analysis”
        • The discipline of examining the business aspects of the enterprise and describing it
      • Preliminary questions
        • What precisely is to be examined?
        • How to describe it?
        • If analysis is restricted to examination and description, at what point would innovation take place?
    • 7. “ xxx Architecture”
      • “ Enterprise Architecture”
        • “ The discipline of architecting the enterprise”
          • This definition applies to the object of the enterprise
      • “ Business Architecture”
        • Part of the Enterprise Architecture that focuses on the business aspects
          • According to the Enterprise System Topology, there are three “business” aspects that must be isolated for a proper description: semantic (core business knowledge), pragmatic (action), geographic (location)
            • See below
      • “ IT Architecture”
    • 8. “ Architecture”
      • A metaphoric use of the term
        • Business Architecture, Enterprise Architecture, IT Architecture, etc.
      • Usual meaning
        • “ The art and study of designing buildings”
        • “ The design or style of a building or buildings”
            • Source: Oxford Dictionary
      • In our context
        • A discipline that deals with the enterprise or an aspect of the enterprise as a whole and establishes the high-level decisions needed
          • Architecture is about the main decisions that structure and transform the system
      • Preliminary questions
        • Which aspects?
    • 9. Positioning Business Architecture SY9-03
    • 10. Enterprise transformation
      • Disciplines involved
      Operation Transformation SY9-03
    • 11. Business: the right description
      • Approach by activity
        • Classical approach
          • Flawed with local variation
          • Functional & hierarchical breakdown structure
      • Semantic modelling
        • Additional approach
          • Move to genericity
          • New solution to cope with complexity
      Pragmatic aspect Actors & organisational entities Process & use-cases Activities Business objects, real objects (Information+Transformation+Action) Objects Semantic aspect Refers to SY9-03
    • 12. Software: the optimal structure
      • Determine the software structure from the business description
        • Applying MDA standard
        • Independently from technical choices
          • Technical Target free
          • Long term
      Pragmatic aspect Actors & organisational entities Process & use-cases Activities Business objects, real objects (Information+Transformation+Action) Objects Semantic aspect Logical aspect Derives Derives Logical services & aggregates (logical machines…) SOA SY9-03 Core Stratum Organization Stratum Interaction Stratum
    • 13. Impact on the IT system FD FD FD FD Caricature of an architecture based upon functional approach Logical blocks take in charge functional domains Which structure the pragmatic model It stems from that important dependencies or redundancies since same business objects are used inside many functional domains BO BO FD FD FD FD OD OD OD OD OD Outlined logical architecture according to Praxeme method
      • Several logical blocks match with the objects domains from semantic model.
      • Dependencies obey topological constraints
      • Between strata (“Business Core”, “Organization”, “Interaction”)
      • Coupling reducing,
      • No dependency between FD, unless special cases,
      • etc.
      FD: functional domain BO: business object OD: objects domain SY9-03
    • 14. Conclusion on BA disciplines
      • Business Architecture/Analysis scope
        • Only the business aspects
          • Semantic aspect: the core business knowledge
          • Pragmatic aspect: the business activity
        • Out of scope
          • Software aspect, Hardware aspect…
        • The logical aspect is an intermediary aspect
          • Can be considered for negotiating investments and roadmaps
      • Consequences of introducing the business objects in the description of the business
        • Capturing the core business knowledge
        • Isolating what is more likely to be shared among the companies
        • Adopting a new standpoint and stimulating innovation
          • In matters of organization and business processes
        • Providing new insights that leads to overhauling the IT system
    • 15. A comprehensive approach
      • How to situate business architecture?
        • Its place on the entire methodological framework
      SY9-03 2
    • 16. Position
      • As a result, Praxeme situates the disciplines of BAs against the Enterprise System Topology
      SY9-03 Possible negotiation Contribution Exclusive responsibiliy, ownership
    • 17. Recap
        • Business Architecture
          • Overall view
          • Making decision on the system scale
        • Business Analysis
          • Detailed view
          • Expressing the business knowledge, describing the business practices
        • Business Design
          • Praxeme encourages design in matters of business
    • 18. Scoping or “political” aspect SY9-03 3
    • 19. Conclusion
      • Roles related to business architecture
      • Responsilities
    • 20. Clarifying responsibilities Logical Architect Organization designer Technical Architect Strategist Business view IT view Business Architect Business Analyst SY9-03
    • 21. Roles related to business description
      • Business Architect
        • The one who makes the overall decision and is the guardian of the long-term vision
      • Business Analyst
        • Involved in operations (projects), bring the details
      • Business Designer
        • The mandate for creating new business practices must be explicit
          • Need for distinguishing both roles?
      • Business Expert
        • They have the knowledge, not necessary the skills for expressing it in the right way
      • Modeler
        • They master the techniques of representation, not necessarily the content (the knowledge)
        • Can be specialized (by aspects…)
    • 22. Responsibilities of business architecture/analysis/modeling
      • Take into account the general directives (strategy…)
      • Understand the business: practices, needs, opportunities
      • Anticipate the changes
      • Describe the business in such a way that:
        • The business knowledge is captured and protected
        • The description can be easily enacted by other actors (e.g. IT designers)