1 / 10

Components and Reuse

Components and Reuse. Tom Carlson National Center for State Courts. The Problem. The problem IEPDs were being developed from scratch, often in isolation Model gives loads of flexibility Similar concepts implemented in dissimilar ways

gail-bowman
Download Presentation

Components and Reuse

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Components and Reuse Tom Carlson National Center for State Courts

  2. The Problem • The problem • IEPDs were being developed from scratch, often in isolation • Model gives loads of flexibility • Similar concepts implemented in dissimilar ways • Short example: PersonFullName versus PersonGivenName combined with PersonSurName • Makes interoperability hard

  3. What We Did • Developed a bunch of court IEPDs • Looked for commonalities • For example, most included: • People of some sort • A court of some sort • Built court components using those commonalities

  4. What It Looks Like • Data Modeler Domain Model Thingie

  5. What It Looks Like • Data Modeler Domain Model Thingie

  6. Limitations • Locked in a proprietary tool • It’s a nice tool, but it’s proprietary • No mechanism for sharing these components, outside of the proprietary tool • No mechanism for using components built by others in other ways

  7. Why It Doesn’t Matter • Moving to a Service Oriented Architecture resolves the problem • Exchange-based IEPDs will become Service-based IEPDs • Those services will be composed of micro-services • Composability is a principle of SOA • Think fractals • Those micro-services become the components • The process of defining these services creates the components too! Sweet!

  8. What We All NeedTo Do Instead • Stop defining IEPDs in terms of exchanges • Services based on “as is” exchanges result in services that codify “as is” processes • Need to be able to create “to be” processes from the services • Think of a code library • If based on legacy code… • …then will only be good for coding legacy apps

  9. What We All NeedTo Do Instead • Start doing Functional Decompositions of the Business • What is it that we really do • From that decomposition, we can determine the services available • Then we can create new business processes from these services • This could be done with JIEM, with some significant changes • We will need the Justice Reference Architecture (JRA) in order for this to happen

  10. For More Information • Contact Me: • Tom Carlson • tcarlson@ncsc.dni.us • For Service Oriented Architecture (SOA) • Scott Fairholm • sfairholm@ncsc.dni.us • For Justice Reference Architecture (JRA) • Tom Clarke • tclarke@ncsc.dni.us

More Related