Your SlideShare is downloading. ×
  • Like
Context Models v2 (ppt)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Context Models v2 (ppt)

  • 194 views
Published

 

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
194
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • We did a similar thing when I invited you to this presentation. I sent you a message, you responded, etc. End result you showed up at this meeting. I could have accomplished the same thing with a form and enrollment and signatures and hand delivered letters.
  • business semantics is based on fundamental categories or predicates. The most important core categories are the following: 􀂄 Actors 􀂄 Messages 􀂄 Subjects or objects 􀂄 Locations 􀂄 Events From these, we can achieve yet another set of more abstract, derived categories: 􀂄 Business exchanges 􀂄 Business processes 􀂄 Business roles 􀂄 Business process activities and decisions 􀂄 User interfaces/formulas/ decision rules 􀂄 Business relationships 􀂄 Business rules Each of these derived categories is a configuration of the actors, messages, and so forth of the core categories. In the following sections, we describe both the core categories and the derived categories. We discovered the major core categories (actors, messages, subjects/objects, locations, and events) not theoretically but by analyzing why a set of rather simple drawings we now call context diagrams were so effective in helping people to understand business systems environments.3 Figure 1 shows a simple context diagram. Context diagrams show only two kinds (or categories) of things explicitly: actors and messages. When we first started using them, the idea was to represent people, organizations, or systems communicating with other people, organizations, or systems with a minimum of other information. Actors are shown in context
  • Modeling Actors, Subjects, and Messages The first thing to understand about actors (individuals, organizations, and systems) is that in the real world, they exist independently of one another. This is what philosophers call “ontological” independence. Customers, for example, are independent of one another. I may physically inherit genes from my parents, but after a certain age, I don’t physically depend on them for my existence. Things in the real world that are independent of one another ought to be modeled as independent entities or classes in corresponding business systems models. If Frank Jones and Frank Smith are separate customers, they need to be assigned different identification numbers and have their attributes collected and updated independently as well. The same holds true for the subject (objects) category. Subjects are independent things; they are individual products (such as hammers, wrenches, or screwdrivers), so they should have unique identification numbers as well. Historically, only expensive products such as cars and computers and television sets have had truly unique IDs (i.e., serial numbers). But with the emergence of radio frequency identification (RFID) technology, the day is coming when nearly every produced product will have its own unique ID, and our business systems will need to be prepared to model billions of unique IDs and capture a whole range of new information about that product including, perhaps, current location and status. The bottom line is that from a business semantics standpoint, actors and subjects are modeled in simple tables with unique IDs (see Figure 10). The fundamental data model of messages (transactions) is only a bit more complex than the data models for actors and subjects. In general, there are two parts to a message: a message header and message line item. Figure 11 shows a typical message data structure. The actor, subject, and message data models are the building blocks for most major business systems (we’ll address event/time and location information later). In a sense, actors and subjects represent the nouns of our business semantics sentences (propositions), and messages represent the verbs. With them, we can construct the basic model for a business communication.
  • System A feeds message to Actor B System A needs a data interface to System A Test, The a new Message from System A Test to Actor B. Then a comparison report to compare System A output to System B output
  • Early on we noted that there was a lot of communication going on with our business partners. We collected the communication flows from the individual business area context models and created an internal/external communication master model. Improving our agency’s communication and relationships with our business partners is an agency priority. Everyone knew about their part of the communications but no one knew about them all.
  • This is a sample of a Organizational based Context flow. Since we only identified the direct interaction to externals we lost the 2-x level interaction. EX Consultant to Design to Traffic.
  • This is an example from the Business partner perspective. Now try to estimate how this picture looks if you include the other state agencies.
  • We did a lot of models and we did not identify information fro a primary system going to anyone outside of KDOT. So we went back to those groups who were receiving information from the system and ask questions around what they did with this information. In a lot of cases they either reformatted it and sent It on to another group inside the agency. Or they repackaged it and sent it to someone outside the agency. Our State staff have almost been trained to be in the middle of an information flow to other sources from systems. As we ask what value they add to the information flow we really get to the real questions around what the best alternative for a system design might look like.
  • Don’t be surprised if you have to do 2-3-4 levels of models for clarity around one information flow. At a high level it might be purchase order, at the next level it might be the model above. At the third level it might include digital signatures, multiple bids, partial shipping papers, multiple receipts, multiple payments. And don’t be surprised if inside of one role you actually discover 2-3 other roles inside of that office. IE Payment staff may break down into recipt of documents, payment authorization, payment distribution, vendor monthly summary audit.
  • Roles in a lot of cases are unique within an organization unit. IE Chief Procurement, Bureau of Computer Services Bureau Chief. Some roles are agency wide. Some are unique within a division, IE Area Engineer.
  • Try to put yourself in these business partners position and imagine the various types of communication you receive from the state on a steady basis. If we can make their life easier and it doesn’t cost us anymore this is good business relations.
  • Copy the today version of the model. Add in a New message flow. Label it New, or modified. Highlight the differences. Focus on the capabilities differences from each actors perspective. See if you can bypass any of the actors or clarify the value added by that actor.
  • For every hour of a modeling session plan on 4-20 hours of follow up efforts Clean up the presentation Make the behind the scene associations, Break into multiple models for clarity Verify the text and definitions, Distribute to team members ( web sites help) and edit.
  • Temptation to include all things on this model, Business functions, Activities, People, Have someone who does not know the topic area review to see if they recognize the actors and messages.

Transcript

  • 1. Context Models Part of Enterprise Architecture Training Bill Roth Chief Information Technology Architect State of Kansas [email_address]
  • 2. Agenda
    • What is a Context Model
    • How do I build one
    • How do I use it
    • How does our agency use it
      • How would another agency see it
    • Why should I care
    • Where does this fit into the big picture
  • 3. What is a context model
    • A model to show any information flow from one source to another.
    • An information flow can be any format
      • Text, voice, reports, video, financial, mail, web, forms, signatures, etc.
  • 4. Simple demo KDOT Supplier KDOT Purchaser Request Bid Current Bid Purchase Order Item requested & shipping order Payment Invoice
  • 5. Simple demo KDOT Supplier KDOT Purchaser Request Bid Current Bid Purchase Order Item requested & shipping order Payment Invoice ACTORS Messages
  • 6. Define Context
  • 7. Define Context Actors Can be Groups, Roles, Systems Examples KHP, Dispatchers, EADCR
  • 8. Define Context Messages Any Information sent from one place to another, In any format Example, accident form, dispatch notice All Types Text, voice, radio, form, report, video, image, ect
  • 9. Define Context Actors outside of topic area Actors inside of topic area
  • 10. Actors Can be Groups, Roles, Systems Bureau Of Computer Services Bureau Chief Bureau Chief Of Computer Services CPMS CMS Email System Area Engineer Designer Ben Nelson DB2 Don’t use personal names or technology, both will change Use the level of Detail that is appropriate for the topic.
  • 11. Messages Actor A Actor B Daily Report Financial Transaction Voice Message Yearly Report Request for Information Batch File Form Signature XML data Role Specific information Receipt Acknowledgement If in doubt put it down, You can clarify it later For every Yin there is a Yen. Look for the completeness
  • 12. Message questions
    • What is the basic information flows
    • How about:
      • Daily Cycles
      • Yearly cycles(FY, Calendar, Fed FY, Budget Cycle,
      • Monthly Cycles, Report distributions, Financials, status reports,
      • Get many levels of the organization involved. Some reports have been delivered so long the current managers may not even be aware of them, especially if they are automated.
    • Keep asking questions until they run out of answers, or you run out of time.
    • Messages are always depicted with one-way arrows.
  • 13. Business semantics based on fundamental categories or predicates
    • most important core categories are the following :
      • Actors
      • Messages
      • Subjects or objects
      • Locations
      • Events
    • From these, we can achieve yet another set of more abstract, derived categories:
    • Business exchanges
    • Business processes
    • Business roles
    • Business process activities and decisions
    • User interfaces/formulas/ decision rules
    • Business relationships
    • Business rules
  • 14. Message as a document Copyright Cutter Consortium & Ken Orr
  • 15. Message as Data Copyright Cutter Consortium & Ken Orr
  • 16. What do you do with a context model
    • Look for sequences of messages, These are Work flows
    • Cyclical stuff can be scheduled
    • Any Message from a system is either an interface or a report.
      • Look for commonalities, these can be a service
    • Any message that is a response to a request can be a service
  • 17. So now this Context becomes? KDOT Supplier KDOT Purchaser Request Bid Current Bid Purchase Order Item requested & shipping order Payment Invoice ACTORS Messages
  • 18. Define Business Process
  • 19. A Defined Business Process Now you can ask about the activity that creates the message Actors control each swimlane Activity to do something Message or content
  • 20. Why are we using Context Models?
    • For Clarity, for you yes, but mostly for Other Agency Staff, Use their terms, They need to see their stuff on the models.
    • For completeness
    • For separation of things to decompose a project into identifiable pieces
    • For identity of cycles, Business processes
    • For Identity of services being delivered, ?automated, Scheduled, Extended, customized
  • 21. So we identified an interface, now what?
    • If I am going to rewrite the interface?
      • How can I build a detour to keep messages flowing while new work is being tested
      • How Can I build verification to ensure new work matches old work
    • I can associate the data with the Interface
    • Is there any thing you can propose to add value to the interface
    • Is the interface essential
    • Identify the metrics of the Interface, frequency, volume, size, type,
    • Can the Type change, IE Voice to VOIP
  • 22. So I identified a Business process, Now What
    • Come Back next month for Business Process discussion
    • Model out Business Process, Don’t be surprised if you find new message flows
    • Is there signatures needed that were overlooked
    • Can the Business process be automated
  • 23. How many types of Context Models are there
    • As many as you need. We have done them
      • System to system only
      • Agency to agency only
      • System centered, total flows to all end points
      • Business Area centered, IE Construction
      • Organization area centered, IE Local Projects
      • Interagency (IE Water Office, KCJIS)
    • There are a lot already done, Identify your topic and request all current messages for that topic
    • Give feed back if someone else’s model is not accurate
  • 24. KDOT's Business Partners KDOT Accident Reports, Traffic Impact Incidents Road Conditions, Traffic Status Vehicle Accident Analysis "Drug Testing"/Drivers License Checks, Project Plans, Vehicle Usage, Payment Information Invoices, Transportation Statistics, GIS Views Research Information Incidents, Problems, Permit Applications 511 responses, KANROAD responses, Project Information Invoices, Permit Applications, Contract Status, Utility GIS Info Project Plans, Project Schedules Contracts, Payments and Schedules Design Plans, Weekly Accomplishments, Invoices, Collaboration Requests for Bids, Contracts, Plans, Change Orders Bids, Invoices, Status reports Project Plans, Invoices, Contracts Funding Limits 5 year plans, TIP Plan Invoices, Local Payments Project Plans, Invoices, Contracts Funding Limits 5 year plans, TIP Plan Invoices, Local Payments Grants, Loans Vehicle Information, Inspection Information Vehicle Reports, Applications, Ridership Information Permits, Road Conditions, Detours etc. Travel and traffic info, Road Conditions, Detours Incidents, Problems, Permit Applications Info req., incidents, problems Req. for info, eGov transactions Requested info, eGov transactions Consultants, Design Contractors Cities Counties Public Transit Authorities Law Enforcement Other State Agencies Universities and Colleges Public Utilities Truckers, Trucking Co Motorists Other States and Federal Agencies
  • 25.  
  • 26.  
  • 27.  
  • 28. The Models don’t appear complete, What did I do wrong
    • For 30 years we have been building solutions to feed stuff to agency Staff. Then they do something with it. They:
      • Import it to Excel/Access
      • Generate form letters from Word, Mail out packets
      • Separate and distribute to other parties
      • Incorporate this with other information and create reports then distribute
    • If It goes to someone in your agency, Find out what they do with it. If they do nothing with it it may be a dead end. (mostly they just don’t think about what they do as adding value)
    • Basically keep asking questions until you see the real end customer And then ask what the real end customer does with it.
  • 29. Things you can do for clarity Put the Organization roles inside the Organization units KDOT Supplier KDOT Purchaser Request Bid Current Bid Purchase Order Item requested & shipping order Payment Invoice ACTORS Messages Purchaser Payment staff Receipt clerk Salesman Shipping Officer Billing Officer Connect the messages to the roles, You can see there is now multiple parties involved in approval and authorities
  • 30. Behind the scenes associations
    • Associate Actors with Organization hierarchy
    • Organize Roles with Organization if unique
    • Associate Messages with data definition
      • Abstract (IE Voice Data)
      • Unique(IE CPMS Project table)
      • If possible Identify the Key of the message (IE Project ID, Voucher Number)
    • You can do this for your project,
    • We will work with you to do this for total agency models.
  • 31. Agency and Your Business Partners PS We may not be the only agency who works with these business partners KDOT Supplier KDOT Purchaser Request Bid Current Bid Purchase Order Item requested & shipping order Payment Invoice ACTORS Purchaser Payment staff Receipt clerk Salesman Shipping Officer Billing Officer These are Relationships to manage & points for competition Suppliers Customers Citizens Legislature Other Agencies Cities Counties
  • 32. Look at Business partners Perspective
    • How many ways to deal with different agencies
    • How many types of messages are they getting
    • Can you help them automate by making something available (IE a data file vs a hard copy report)
    • Single Authority(IE PKI)
    • Volume of information exchange
  • 33. As other agencies get these models
    • Look for common business partners
    • Look for common ways for secure interactions
    • Look for common types of transactions
    • Look for competitive alternatives
    • Ask them better ways to work with the state
    • Look for common services, yours-theirs
  • 34. Context Model & Strategic Intent
    • Look for Message flow causing problem
    • Highlight message flows that could be customized to business partner needs
    • Highlight Message flows that could ease pain for different roles in KDOT, IE Inspectors
    • Highlight areas where all messages are transactions, No summary, no cyclical, No support for strategic measurements
    • Highlight areas you are requesting to invest efforts in.
  • 35. Future
    • Did I mention that you could put future systems, future message flows, future roles & actors on a model
    • Maybe a before and after model
    • Or color coded(note that these don’t copy well)
  • 36. How do I get a Context Model
    • Conducting a modeling session
    • Room requirements
    • Preparation for a session
    • People involved
    • Technical requirements
    • Immediate feedback or next meeting feedback
    • Follow up to a session
    • Getting approval of the session deliverables.
  • 37. Keep it free but disciplined
    • Discipline and QA
      • Actors, messages, systems
      • How do you know if you have violated the basics.
    • Combining low level context models
      • To get summary from a single perspective. IE Business partner
      • To get summary from a single system
      • To see where gaps may exist
    • Get other perspectives, Reviews
    • Note you can also get this from existing documentation but it helps if the business community helps you build them.
  • 38. Connecting Context models to Project plans
    • Connecting Context models to project staging
    • Connecting context models to testing plans.
    • Connecting context models to Requirements gathering
    • Connecting Context models to Design
    • Connecting Context models to implementation phases
      • Like a KDOT Project, A detour needs to be built first if you are going to work through traffic, and verification
  • 39. Technology Architecture
    • When you connect message flows to technical implementations, you can
      • Use the Context Models to identify big picture needs and changes
      • Develop Macro level considerations for Technology Architecture replace-ability.
      • Develop Phased evolutions for legacy systems.
  • 40. Why Do I care about a message? Every Message becomes a program eventually. And each program is tied to associated technologies and is an investment for KDOT. When you look at a message in current solution and you look at the message in Future solution. Look for technology and customization options that you can add to make life easier for our customers CMS System Contractor Area Engineer Contractor Status Report Mainframe DB2 Views XXX Program XXX Server Web Server Business Objects Server SSL Layer Program XXX Client Contract ID Option AE ID Option Schedule Options Authenticate Parameters Report Parameters Data Service USER Sees this We Build this
  • 41. Conclusion
    • Understanding Your Business
    • Understanding relationship between your Business, Its strategy, Its business Partners, and current and future IT Systems.
    • Clarity is good,
    • Use Big Pictures and Big Paper, Or High level and low levels related. This is not a 8 ½ X 11 exercise.
  • 42. Focus on KDOT’s Process, Supporting Data and Communication Methods Today’s Session Strategy objectives goals critical success factors Organization Structure business units roles skills business partners Business Processes activities goals workflow Information data letters/faxes drawings email Applications programs systems spreadsheets Technology software hardware network Enterprise Architecture
  • 43. Possible Future Topics
    • Business Processes Next Month
    • Radar Charts
    • Value Chains
    • Data, Data Warehouse, Data models, etc
    • Technical
    • Application decomposition
    • Legacy replacement