4/30/10 A very first draft on a concrete Extended Enterprise ...

709 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
709
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Documentatie van de uitvoer staat los van de uitvoer zelf: je documenteert misschien wel alle berichtenuitwisselingen op businessniveau centraal (vanuit standpunt van de eigenaar van die EEAD), maar de concrete uitwisseling, de IT-lagen kunnen verspreid worden???? Indien er geen directe relatie is ts company 2 & 3, dan is alle info over berichtenuitwisselingen centraal bij comp 1 opgeslagen. Als er wel uitwisselingen zijn ts 2&3, dan moeten zijn dat modelleren in hun EEAD. Eventueel kan dit dan gewoon gecopieerd worden naar de EEAD van comp 1, indien deze meer inzicht wil in het proces.
  • Indien er geen directe relatie is ts company 2 & 3, dan is alle info over berichtenuitwisselingen centraal bij comp 1 opgeslagen. Als er wel uitwisselingen zijn ts 2&3, dan moeten zijn dat modelleren in hun EEAD. Eventueel kan dit dan gewoon gecopieerd worden naar de EEAD van comp 1, indien deze meer inzicht wil in het proces.
  • Eigenlijk willen we een volledig, geintegreerd overzicht van de EE. Echter indien we alles samen zouden brengen in geintegreerde modellen, dan zouden deze veel te groot en onhandelbaar worden, en zouden deze veel te veel irrelevante info bevatten voor elke partij. Daarenboven zou het enorm moeilijk zijn deze op te stellen (bv. geen eenduidige benaming van data: semantisch probleem) We zien een oplossing in het uiteen halen van de totale architectuur in een aantal componenten: 1) de individuele architectuur van elk bedrijf afzonderlijk; 2) op niveau EE: business gegevens (geaggregeerde data), business processen (één voordeur voor de klant verbergt de deelprocessen hierachter, dit is rij 1) en 3) niet-business zaken op EE niveau: bv. publieke processen (zouden ts business processen zitten op rij 2 EE) Die publieke processen, EEgeaggregeerdedata e.d. moeten allemaal in technologie gegoten worden, dus zijn de onderste lagen van het Zachmanframework ook nog relevant. Kunnen we 2) en 3) uit elkaar halen? Wellicht niet, en hoeft wellicht ook niet: binnen een onderneming zijn er ook boodschapuitwisselingen (zoals de public processen) tussen systemen, en die worden ook gemodelleerd binnen de eigen architectuur. Het komt er dan op neer dat elke onderneming voor zijn business-web het paarse kader moet bouwen (+ zijn eigen architectuur). Dit paarse kader is evenwel een Zachman framework. We krijgen dus gewoon een tweede dimensie aan het framework. Componenten van dit paarse kader zijn voor sommige ondernemingen hetzelfde. Deze ondernemingen moeten/kunnen dit paarse deel samen ontwikkelen. How do A en B build their business web AD? Some part is overlapping (e.g. the public process is inverse; EEdata is available), some is not. In essence, everybody would have to use the same work products! De individuele architectuur mag in principe om het even welke work products gebruiken bij het opstellen ervan. Bij het gebruik ervan is het echter handig als alle ondernemingen dezelfde diagramma’s hebben, zodat die gemakkelijk te verstaan zijn bij onderhandelingen. De EEAD moet in principe ook al bij het opstellen eenzelfde work product vooropstellen voor alle ondernemingen. Zo’n EEAD kan duidelijk de relaties modelleren ts verschillende bedrijven, oorsprong van data weergeven, overzicht van totaal process, interafhankelijkheden,… + standaarden indelen, hun mogelijkheden en beperkingen tonen. Immers, het is wellicht nodig alle perspectieven te bevatten (want een B2B systeem is in dat opzicht gelijk aan een gewoon intern systeem), en misschien ook om elke focus te bekijken (??).
  • Wat doe je met een proces dat je aanbiedt aan de buitenwereld, en dat je volledig zelf voorziet, zonder hulp van partners? In EE of in individual enterprise? Op allerhoogste niveau in de EE (en anders in de individuele)? Want dit is de voordeur van je bedrijf. Dit biedt mogelijkheden om dit proces later op te splitsen, te verdelen… Waar ligt de lijn ts informatiebehoefte om EE te vormen en informatiebehoefte om EE te managen eens ze er staat? Elk bedrijf heeft z’n eigen data, en eigen semantiek. Publieke processen worden uiteindelijk ook door de bedrijven zelf uitgevoerd: maken zelf de berichten op. Hoe breng je die technische zaken in de ADs? Hebben te maken met publieke processen (duss EEAD) en worden gemaakt binnen individuele onderneming (individuele AD). Je moet de choreografie los splitsen van de functionaliteit, anders zit je bovendien niet meer loosely coupled bezeg. KWALITEIT zit ingebouwd in het raamwerk: je wordt verplicht loosely coupled te werken. Je kunt niet zomaar een call doen naar een service van een ander bedrijf. Hiervoor moet je via de EEArchitectuur. Dus: Procedure A(B,C) Begin… End; WSCall D(B, E) Procedure L(M, E) Begin, End; GESTUURD VANUIT EEAD ipv Procedure Big (A, B, C, E, M) Begin … WSCall (B, E); … End Als er een externe partij bij het geheel betrokken is, gebeurt orchestratie op niveau van EE. De Bovenste rij van de EEAD is de voordeur van het bedrijf, deze kan ofwel onmiddellijke controle geven aan de individuele AD in de tweede rij, of controle bewaren op EEAD-niveau indien andere partijen bij de orchestratie betrokken zijn.
  • 4/30/10 A very first draft on a concrete Extended Enterprise ...

    1. 1. Agenda <ul><li>1. Overview Classic Zachman Framework </li></ul><ul><li>2. Classic Zachman Framework – concrete example </li></ul><ul><li>3. Example of an Extended Enterprise process </li></ul><ul><li>4. Very first draft of an Extended Enterprise Architecture Framework </li></ul><ul><li>5. Why such a framework?/Deliverables PhD </li></ul>A very first draft on a concrete Extended Enterprise Architecture Framework Frank Goethals – SAP leerstoel 23/04/2003
    2. 2. Basis: The Zachman Framework 1 2 3 4 5 6 Contextual Conceptual Logical Physical As Built Functioning Why Objective Precedent Objective Who Organization Reporting Organization When Event Cycle Event Where Node Line Node What Entity Relationship Entity How Input Process Output Different Persons Basic English Questions
    3. 3. <ul><li>Row 1 – Scope </li></ul><ul><ul><li>External Requirements and Drivers </li></ul></ul><ul><ul><li>Business Function Modeling </li></ul></ul><ul><li>Row 2 – Enterprise Model </li></ul><ul><ul><li>Business Process Models </li></ul></ul><ul><li>Row 3 – System Model </li></ul><ul><ul><li>Logical Models </li></ul></ul><ul><ul><li>Requirements Definition </li></ul></ul><ul><li>Row 4 – Technology Model </li></ul><ul><ul><li>Physical Models </li></ul></ul><ul><ul><li>Solution Definition and Development </li></ul></ul><ul><li>Row 5 – As Built </li></ul><ul><ul><li>As Built </li></ul></ul><ul><ul><li>Deployment </li></ul></ul><ul><li>Row 6 – Functioning Enterprise </li></ul><ul><ul><li>Functioning Enterprise </li></ul></ul><ul><ul><li>Evaluation </li></ul></ul>1 2 3 4 5 6 Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Who When Where What How Basis: The Zachman Framework
    4. 4. Agenda <ul><li>1. Overview Classic Zachman Framework </li></ul><ul><li>2. Classic Zachman Framework – concrete example </li></ul><ul><li>3. Example of an Extended Enterprise process </li></ul><ul><li>4. Very first draft of an Extended Enterprise Architecture Framework </li></ul><ul><li>5. Why such a framework? </li></ul>
    5. 5. Zachman Framework – Row 1 Scope/Planner’s View <ul><li>Data/What </li></ul><ul><ul><li>High-level data classes related to each </li></ul></ul><ul><ul><li>function </li></ul></ul>1 Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How Customer Product Producttype Employee Department
    6. 6. Zachman Framework – Row 1 Scope/Planner’s View 1 <ul><li>Function/How </li></ul><ul><ul><li>High-level business functions </li></ul></ul><ul><li>Data/What </li></ul><ul><ul><li>High-level data classes related to each </li></ul></ul><ul><ul><li>function </li></ul></ul>Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How Sales Production <ul><li>People/Who </li></ul><ul><ul><li>Stakeholders related to each function </li></ul></ul><ul><li>Network/Where </li></ul><ul><ul><li>Locations related to each function </li></ul></ul><ul><li>Time/When </li></ul><ul><ul><li>Cycles and events related to each </li></ul></ul><ul><ul><li>function </li></ul></ul><ul><li>Motivation/Why </li></ul><ul><ul><li>Business goals, objectives and performance measures related to each function </li></ul></ul>
    7. 7. Zachman Framework – Row 2 Enterprise Model/Owner’s View <ul><li>Data/What </li></ul><ul><ul><li>Business data </li></ul></ul>2 Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How Customer Product Producttype Employee Department buys contacts N N N N N 1 1 1 1 N
    8. 8. Zachman Framework – Row 2 Enterprise Model/Owner’s View 2 <ul><li>Function/How </li></ul><ul><ul><li>Business processes </li></ul></ul><ul><li>Data/What </li></ul><ul><ul><li>Business data </li></ul></ul>Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How <ul><li>People/Who </li></ul><ul><ul><li>Roles and responsibilities in each </li></ul></ul><ul><ul><li>process </li></ul></ul><ul><li>Network/Where </li></ul><ul><ul><li>Locations related to each process </li></ul></ul><ul><li>Time/When </li></ul><ul><ul><li>Events for each process and sequencing </li></ul></ul><ul><ul><li>of integration and process improvements </li></ul></ul><ul><li>Motivation/Why </li></ul><ul><ul><li>Policies, procedures and standards for each process </li></ul></ul>Places order Customer Employee Check Credit Customer data Credit not-OK Credit OK Accept/reject Check Stock Product data … . Sales Process
    9. 9. Zachman Framework – Row 3 System Model/Designer’s View <ul><li>Data/What </li></ul><ul><ul><li>Logical data models of data and data </li></ul></ul><ul><ul><li>relationships underlying information </li></ul></ul>3 Customer Employee contacts N N Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How Customer Employee N Cust-Emp 1 1 N
    10. 10. Zachman Framework – Row 3 System Model/Designer’s View 3 Places Order Customer Employee CheckCredit (Custnr, CustOK) Customer DB Response CheckStock (Prodnr, q, StockOK) Product DB <ul><li>Function/How </li></ul><ul><ul><li>Logical representation of information </li></ul></ul><ul><ul><li>systems and their relationships </li></ul></ul><ul><li>Data/What </li></ul><ul><ul><li>Logical data models of data and data </li></ul></ul><ul><ul><li>relationships underlying information </li></ul></ul>IF CustOK Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How <ul><li>People/Who </li></ul><ul><ul><li>Logical representation of access privileges </li></ul></ul><ul><ul><li>constrained by roles and responsibilities </li></ul></ul><ul><li>Network/Where </li></ul><ul><ul><li>Logical representation of the distributed </li></ul></ul><ul><ul><li>system architecture for locations </li></ul></ul><ul><li>Time/When </li></ul><ul><ul><li>Logical events and their triggered responses </li></ul></ul><ul><ul><li>constrained by business events and their responses </li></ul></ul><ul><li>Motivation/Why </li></ul><ul><ul><li>Policies, standards and procedures </li></ul></ul><ul><ul><li>associated with a business rule model </li></ul></ul>
    11. 11. Zachman Framework – Row 4 Technology Model/Builder’s View <ul><li>Data/What </li></ul><ul><ul><li>Database management system (DBMS) type </li></ul></ul><ul><ul><li>requirements constrained by logical data models </li></ul></ul>4 Customer, ID= Customernr Cust-Emp, ID= Customernr, Empnr Employee, ID= Empnr DB2 Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How
    12. 12. Zachman Framework – Row 4 Technology Model/Builder’s View 4 <ul><li>Function/How </li></ul><ul><ul><li>Specifications of applications that operate </li></ul></ul><ul><ul><li>on particular technology platforms </li></ul></ul><ul><li>Data/What </li></ul><ul><ul><li>Database management system (DBMS) type </li></ul></ul><ul><ul><li>requirements constrained by logical data models </li></ul></ul>Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How Dell Win 2000 Server Credit Checking (C++) Stock Checking (Visual Basic) <ul><li>People/Who </li></ul><ul><ul><li>Specification of access privileges to </li></ul></ul><ul><ul><li>specific platforms and technologies </li></ul></ul><ul><li>Network/Where </li></ul><ul><ul><li>Specification of network devices and their </li></ul></ul><ul><ul><li>relationships within physical boundaries </li></ul></ul><ul><li>Time/When </li></ul><ul><ul><li>Specification of triggers to respond to system </li></ul></ul><ul><ul><li>events on specific platforms and technologies </li></ul></ul><ul><li>Motivation/Why </li></ul><ul><ul><li>Business rules constrained by information </li></ul></ul><ul><ul><li>systems standards </li></ul></ul>
    13. 13. Zachman Framework – Row 5 As Built/Subcontractor’s View <ul><li>Data/What </li></ul><ul><ul><li>Data definitions constrained by physical </li></ul></ul><ul><ul><li>data models </li></ul></ul>5 Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How DBD Name=STDCDBP, Access=HDAM, RMNAME (DLZHDC10,3,100,600) DATASET DD1= STDCBC …
    14. 14. Zachman Framework – Row 5 As Built/Subcontractor’s View 5 <ul><li>Function/How </li></ul><ul><ul><li>Programs coded to operate on specific </li></ul></ul><ul><ul><li>technology platforms </li></ul></ul><ul><li>Data/What </li></ul><ul><ul><li>Data definitions constrained by physical </li></ul></ul><ul><ul><li>data models </li></ul></ul>Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How Procedure CreditChecking (customernr, Accept); Begin SearchCustomerdata (customernr, limit); if limit > (GetProductPrice(prodnr)*q) then Accept := true else Accept := false; End; <ul><li>People/Who </li></ul><ul><ul><li>Access privileges coded to control access </li></ul></ul><ul><ul><li>to specific platforms and technologies </li></ul></ul><ul><li>Network/Where </li></ul><ul><ul><li>Network devices configured to conform to </li></ul></ul><ul><ul><li>node specifications </li></ul></ul><ul><li>Time/When </li></ul><ul><ul><li>Timing definitions coded to sequence </li></ul></ul><ul><ul><li>activities on specific platforms and technologies </li></ul></ul><ul><li>Motivation/Why </li></ul><ul><ul><li>Business rules constrained by specific </li></ul></ul><ul><ul><li>technology standards </li></ul></ul>
    15. 15. Zachman Framework – Row 6 Functioning Enterprise <ul><li>Motivation/Why </li></ul><ul><ul><li>Operating characteristics of specific </li></ul></ul><ul><ul><li>technologies constrained by standards </li></ul></ul><ul><li>Function/How </li></ul><ul><ul><li>Functioning computer instructions </li></ul></ul><ul><li>Data/What </li></ul><ul><ul><li>Data values stored in actual databases </li></ul></ul><ul><li>People/Who </li></ul><ul><ul><li>Personnel and key stakeholders </li></ul></ul><ul><ul><li>working within their roles and responsibilities </li></ul></ul><ul><li>Network/Where </li></ul><ul><ul><li>Sending and receiving messages </li></ul></ul><ul><li>Time/When </li></ul><ul><ul><li>Timing definitions operating to sequence </li></ul></ul><ul><ul><li>activities </li></ul></ul>6 Contextual Conceptual Logical Physical Integrated Functioning Contextual Conceptual Logical Physical Integrated Functioning Why Why Who Who When When Where Where What What How How
    16. 16. Agenda <ul><li>1. Overview Classic Zachman Framework </li></ul><ul><li>2. Classic Zachman Framework – concrete example </li></ul><ul><li>3. Example of an Extended Enterprise process </li></ul><ul><li>4. Very first draft of an Extended Enterprise Architecture Framework </li></ul><ul><li>5. Why such a framework? </li></ul>
    17. 17. Company A <ul><li>Sells to building contractors, do-it-yourself shops,… </li></ul><ul><ul><li>- Roof Tiles (dakpannen) - Paving Stones (tegels) - Bricks (bakstenen) - Sand (zand) - Mortar (cement) </li></ul></ul><ul><li>To predict their future sales, they could contact a number of architect agencies, but … what is the quality of the data given by these agencies? </li></ul>
    18. 18. The Architect’s process: Row2-Column2 request Customer Architect Check customer profile Check existing drafts Make first drafts Negotiate drafts Make second version Update customer profile Check existing drafts Store material requirements Class 1 Negotiate drafts Make third version Update customer profile Check existing drafts Negotiate drafts Store material requirements Class 2
    19. 19. The Architect’s process: Architect Update customer profile Update customer profile Check customer profile Check existing drafts Make first drafts Make second version Check existing drafts Store material requirements Class 1 Make third version Check existing drafts Store material requirements Class 2 Number of building projects Estimated material requirements Level of trust = 1 Estimated material requirements Level of trust = 2
    20. 20. The Architect’s process: Architect Store material requirements Class 1 Store material requirements Class 2 Number of building projects Estimated material requirements Level of trust = 1 Estimated material requirements Level of trust = 2 Company A Prediction Process Architect Process Step 1 Step 2 Step 3 Step 4 Step 5
    21. 21. The Architect’s process: Row?-Column? New project-ID+ projecttype Estimated material requirements Level of trust = 1 Estimated material requirements Level of trust = 2 Public Business Process Monthly Payment Intermediate Payment
    22. 22. Agenda <ul><li>1. Overview Classic Zachman Framework </li></ul><ul><li>2. Classic Zachman Framework – concrete example </li></ul><ul><li>3. Example of an Extended Enterprise process </li></ul><ul><li>4. Very first draft of an Extended Enterprise Architecture Framework </li></ul><ul><li>5. Why such a framework? </li></ul>
    23. 23. Zachman Company 1 Zachman Company 2 Zachman Company 3 Zachman PTX Customer wants one front door to the business Integrated processes, Gobal data, Location of the PTX, message flows, Contact Persons, …
    24. 24. Zachman Company 1 Zachman Company 2 Zachman Company 3 Zachman PTX
    25. 25. Zachman Company 1 Zachman Company 2 Zachman Company 3 Zachman PTX
    26. 26. D B A C
    27. 27. Two clearly separated Architecture Descriptions per enterprise Extended Enterprise Individual Enterprise
    28. 28. Agenda <ul><li>1. Overview Classic Zachman Framework </li></ul><ul><li>2. Classic Zachman Framework – concrete example </li></ul><ul><li>3. Example of an Extended Enterprise process </li></ul><ul><li>4. Very first draft of an Extended Enterprise Architecture Framework </li></ul><ul><li>5. Why such a framework? </li></ul>
    29. 29. WHY this research? <ul><li>1. Enterprise Architecture Descriptions are useful. </li></ul><ul><li>2. There has been few academic research on enterprise architecture frameworks. </li></ul><ul><li>3. It interests me… </li></ul><ul><li>The concept is universal and is gaining momentum. </li></ul><ul><li>They ease the communication, and the working with complex systems. </li></ul><ul><li>They can serve as a basis for the third level of integration. </li></ul>
    30. 30. Goal <ul><li>Improve and ease the Extended Enterprise integration exercise </li></ul><ul><li>Through: </li></ul><ul><li>1. an unambiguously defined, well-grounded, easily understandable, integratable architecture model for the Extended Enterprise integration exercise, and </li></ul><ul><li>2. a clear, well-grounded, easily understandable method to draw up, maintain, and use the architecture descriptions to their full potential. </li></ul>This includes a link to other processes

    ×