System Architecture for C4I Coalition Operations
•Descargar como PPTX, PDF•
2 recomendaciones•3,419 vistas
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (15)
Similar a System Architecture for C4I Coalition Operations
Similar a System Architecture for C4I Coalition Operations (20)
Más de Real-Time Innovations (RTI)
Más de Real-Time Innovations (RTI) (20)
Último
Último (20)
System Architecture for C4I Coalition Operations
- 1. A System Architecture for C4I for Coalition Operations Gordon A. Hunt – UDT 2013 Spain Chief Engineer, RTI • UCS WG Sub-Committee Chair • Commander USN-R
- 2. Agenda • Background – Open Architecture and Current Approaches • A Coalition is a System of Systems – Definitions and Examples • Interoperability Architecture – It is all about the Data – How to capture and define its meaning – Interoperability by Design
- 3. Background How Do We ‘Do’ Interoperability? What is labeled ‘Open’? © 2013 RTI
- 4. Current Technical Approaches • Protocol Definitions & Standards – Tell me the messages • Open Architecture Mandates – Interoperability on Commonality • (Implementation) Architecture of the Day – Service Oriented Architecture – RESTful Interfaces – … © 2013 RTI
- 5. Advanced Rapid COTS Insertion (ARCI) • Focused, single purpose team – Interoperability by design to same spec – i.e. Interoperability by specification • Short integration cycle – Software- 1 year – Hardware – 2 years • Coordinated teams • Lessons Learned Include – Technology – HW/SW – Contracting, Procurement, – Acquisition, Budgeting – Test & Evaluation © 2013 RTI
- 6. Is Current Practice Working • Recent studies have shown a growth in interoperability policy issuance in DoD – Thousands of pages of directives, instructions, and mandates – Numerous standards and architecture bodies in the DoD • No Correlation between Increased Interoperability and Standards – Standards are necessary, but not sufficient for interoperability • Conventional means of developing platform, unit command, and theater architectures are complex, manpower intensive, and time consuming. – Achieving Interoperability increases complexity – Complexity of systems-of-systems not understood or well managed Can’t make complexity go away, just move where it is © 2013 RTI
- 7. Navy Open System Architecture • Current signed direction – To coordinate business practices promoting OA – Construct a limited number of technical frameworks to improve and promote competition – Develop an Execution guidebook – Lead and guide the workforce – Metrics to measure ‘openness’ and progress © 2013 RTI
- 8. Are these Approaches Sufficient? What is different and unique in coalitions operations? © 2013 RTI
- 10. System of Systems System of Systems • A system of systems is a collection of task- oriented or dedicated systems that pool their resources and capabilities together to create a new, more complex system which offers more functionality and performance than simply the sum of the constituent systems. System A System B System [n] System A System B … System [n] Has a set of >[n+1] capabilities
- 11. System of Systems Properties 1. Operational independence of the component systems 2. Managerial independence of its component systems 3. Evolutionary Independence of the constituent systems 4. Emergent Behavior © 2013 RTI
- 12. Key Non-Functional Requirements for a System • Interchangeability • Replaceability • Extensibility • Integratability System System A System B System System B System C F(A,B) Results in X F(C,B) Results in X A and C provide Equal Capability © 2013 RTI
- 13. Key Non-Functional Requirements for a System • Interchangeability • Replaceability • Extensibility • Integratability System System A System B System System B System C F(A,B) Results in X, Y, Z F(C,B) Results in Y, Z, W C is NOT an Equal Capability, but it Is a suitable substitute © 2013 RTI
- 14. System Key Non-Functional Requirements for a System • Interchangeability • Replaceability • Extensibility • Integratability System System B System C F(A,B) Results in X F(A,B,C) Results in X and Y System A System System B System A System C F(C) Results in Y © 2013 RTI
- 15. System C Key Non-Functional Requirements for a System • Interchangeability • Replaceability • Extensibility • Integratability System B F(A) Results In X F(A,B) Results in Z, where Z=G[f(X), g(Y)] System A System B System A F(B) Results in Y © 2013 RTI
- 16. The Key Non-Functional Requirement for a SoS • Interoperability the ability of systems, units, or forces to provide services to and accept services from other systems, units, or forces, and to use the services so exchanged to enable them to operate effectively together. F(A) and G(B) Become G[F(A)] and F[G(B)] F(A) Results In X System B System A G(B) Results In Y System of Systems System B System A © 2013 RTI
- 17. Levels of Conceptual Interoperability Level 0: No Interoperability Level 1: Technical Interoperability Level 2: Syntactic Interoperability Level 3: Semantic Interoperability Level 4: Pragmatic Interoperability Level 5: Dynamic Interoperability Level 6: Conceptual Interoperability IncreasingCapabilityInteroperation © 2013 RTI
- 18. Level 0: No Interoperability • Requires – A stand alone system • Result – Stand alone systems that have no interoperability • Non-Functional Need Met – None Level 0: No Interoperability Level 1: Technical Interoperability Level 2: Syntactic Interoperability Level 3: Semantic Interoperability Level 4: Pragmatic Interoperability Level 5: Dynamic Interoperability Level 6: Conceptual Interoperability © 2013 RTI
- 19. Level 1: Technical Interoperability • Requires – Communications Infrastructure established • Result – Bits & Bytes are exchanged in an unambiguous manner • Non-Functional Need Met – Replaceability Interchangeability Level 0: No Interoperability Level 1: Technical Interoperability Level 2: Syntactic Interoperability Level 3: Semantic Interoperability Level 4: Pragmatic Interoperability Level 5: Dynamic Interoperability Level 6: Conceptual Interoperability © 2013 RTI
- 20. Level 2: Syntactic Interoperability • Requires – Communications Infrastructure established – Common structure or common data format for exchanging information • Result – Bits/Bytes and the Structure of Data are exchanged in an unambiguous manner • Non-Functional Need Met – Interchangeability and Integrateability Level 0: No Interoperability Level 1: Technical Interoperability Level 2: Syntactic Interoperability Level 3: Semantic Interoperability Level 4: Pragmatic Interoperability Level 5: Dynamic Interoperability Level 6: Conceptual Interoperability © 2013 RTI
- 21. Level 3: Semantic Interoperability Level 0: No Interoperability Level 1: Technical Interoperability Level 2: Syntactic Interoperability Level 3: Semantic Interoperability Level 4: Pragmatic Interoperability Level 5: Dynamic Interoperability Level 6: Conceptual Interoperability • Required – Communications Infrastructure and Common Data Format are established – Common information model is defined for exchanging the meaning of information • Result – Bits/Bytes and the structure of data are exchanged in an unambiguous manner – Content of the information exchanged is unambiguously defined • Non-Functional Need Met – Actual, high-level Interoperability © 2013 RTI
- 22. Integration by Example 7/18/2013 23© 2013 RTI
- 23. Interoperation by Example 7/18/2013 24© 2013 RTI
- 24. Interoperation by Example 7/18/2013 25© 2013 RTI
- 25. Interoperability by Example The procedure is actually quite simple. First you arrange things into different groups. Of course, one pile may be sufficient depending on how much there is to do. If you have to go somewhere else due to lack of facilities that is the next step, otherwise you are pretty well set. It is important not to overdo things. That is, it is better to do too few things at once than too many. In the short run this may not seem important but complications can easily arise. A mistake can be expensive as well. At first the whole procedure will seem complicated. Soon, however, it will become just another facet of life. It is difficult to foresee any end to the necessity for this task in the immediate future, but then one never can tell, After the procedure is completed one arranges the materials into different groups again. Then they can be put into their appropriate places. Eventually they will be used once more and the whole cycle will then have to be repeated. However, that is part of life. - Bransford & Johnson (1972) © 2013 RTI
- 26. It is the Data that Matters How do you Define & Design it? What does the Architecture look like? © 2013 RTI
- 27. MODEL A model is anything used in any way to represent something else 7/18/2013 28© 2013 RTI
- 28. DATA MODEL A data model is a representation that describes the data about the things that exist in your domain 7/18/2013 29© 2013 RTI
- 29. Systems of Systems are Different 7/18/2013 30 System of Systems [n] types of systems [n]sets of requirements + the requirement for Semantic Interoperability many things to express many different representations of those expressions to achieve interoperability © 2013 RTI
- 30. The SOS Data Model Shall… 1. Meet the requirements of all of the constituent systems 2. Support the overarching requirement for Semantic Interoperability 3. Allow for changes to be made to the model without requiring changes to the existing system and application interfaces that use it Formal Language Rigorous Documentation Formal Process 1. 2. 3. We Need A Formal Approach! © 2013 RTI
- 31. Formal Language for Data Modeling • Similar to structured, rigorous programming languages • Ambiguity is not acceptable – Syntax – Semantics Formal Language Alphabet Transformation Rules Formation Rules © 2013 RTI
- 32. Semantics, Ambiguity, and Language Natural Language Representation • A super charger costs 1500 dollars. I wait until the part goes on sale. I can spend 450 dollars, including 8.25% tax. On Monday, the store discounts everything by 50%. Each day an item is not sold, it is discounted another 25%. How soon can I buy my part? Formal Language Representation 7/18/2013 33 Pc = $1500... Pc = $1500´ 1+ 0.0825( ) or $1500 ì í ïï î ï ï = $1,623.75 or $1,500.00 t = tbuywhen P £ $450 @t =1, P = Pc ´ 1- 0.5( ) ì í ï î ï = $811.88 or $750.00 @t ³ 2, P = Pc ´ 1- 0.5( )éë ùû´ t -1( )´ 0.75éë ùû ì í ï î ï =... © 2013 RTI
- 33. Documentation Methodology • Documenting only your messages is insufficient • Documentation doesn’t end at the data model – Your system – Key decisions – Context 7/18/2013 34© 2013 RTI
- 34. Formal Process • Mandates are insufficient with so many stakeholders • Can’t dictate everything, must accommodate many things • SOS DM needs to enforce rigorous well defined processes, not mandate messages 7/18/2013 35 Atomic Elements Elements of Meaning © 2013 RTI
- 35. Putting the Pieces Together 7/18/2013 36 Things to Model from System A Data Model Data Modeling Process Structure Behavior Context representation A representation A representation [n] per a Rigorous and Formal Approach © 2013 RTI
- 36. Data Centric Integration Solution 7/18/2013 37 Legacy System A Mediation Future System C Mediation New System B Mediation • Technical Interoperability – Infrastructure & Protocol • Syntactic Interoperability – Common Data Structure • Semantic Interoperability – Common Data Definition © 2013 RTI
- 37. Who is Doing this Currently? • US OSD and the UCS (UAV Control Segment) – Working Group has built a formal, conceptual model by which to enforce interoperability. © 2013 RTI
- 38. RTI’s Data Centric Integration Solution 7/18/2013 39 Connext DDS Professional DDS-RTPS Wire Interoperability Messaging Real-Time Apps Disparate Apps/Systems Integrator Tools Administration Monitoring Recording Replay LoggingSystem Viz • Connext DDS – Wire Interoperability – Xtypes • Connext Integrator – Mediation • Future Evolutions – More powerful – More flexible – More systems. Working as 1. © 2013 RTI
- 39. Thoughts On Where We Are and Where We Have to Go… • OA is an acquisition concept – It is not a specific technical matter • A large infrastructure to manage OA isn’t needed – No Architecture solely for Architecture • Interoperability has to be by design – By specification works for small teams • Processes need to remain flexible – Systems are dynamic • Need to own the most important aspect of a system, the data. – It content, context, and behavior…. © 2013 RTI
Notas del editor
- Interoperability and Open ArchitectureCurrent practice but…What is it really?Why is it hard?
- VERSUSInteroperability by mediationAPB == Advanced Processing Build
- So, its all good right? Not so fast.Transition out: So, what is missing, how de we get Open Architectures that really deliver on the promise?
- Measure and require designed interoperability
- When we talk about systems and data, we’re usually having conversations about interfaces, integration, and achieving interoperability. So now I’m going to talk a little about integration and interoperation of systems.
- <automate>
- Using a Quality Attribute Methodology, that supports the Business, Non-functional RequirementsThe Key Architectural Drivers of an Open System are:How do we achieve these KADs?How do we achieve these in Open Architecture?
- Where do we see integration in our everyday lives? When I really need to charge my phone (I forget…quite often, really), I grab my cable and I plug it in. One end of the cable connects to the phone, and the other end to the power source. After a bit of time, the phone is charged. This simple example demonstrates an everyday integration of systems: a phone and the power system. In this case, the two interfaces are designed in such a way that they work together – no adapter or mediating component is required.
- To successfully enable systems to interoperate, they require a matching of specifications or interface standards through some means. Say this power cable is for my cell phone and I’m in Spain, visiting a friend. I just arrived at my hotel, and my phone is dead. I grab my phone and my cable and go to plug it in and… oh. Right. Complete interface mismatch. These components were not designed in a way that allows for them to be integrated right away. But I really need to charge my phone! Since these systems were not designed to work together, a solution must be architected if I require them to interoperate… They can’t interoperate without some element of mediation.
- Interoperability can be achieved through a mediation layer – here, an adapter – that allows for the 2 systems to be integrated without requiring a change be made to one or both of their interfaces. I don’t need a new power cable to charge my cell phone while I’m in Europe, if I by the adapter.In the integration example, I achieved interoperation without the need for the mediation component – the “magic box”. In those cases where I require an element such as this to achieve interoperability, that interoperation is achieved by architecting a solution that allows for me to integrate my systems together. Common examples include standards matching and adapters
- A model is anything used in any way to represent something else. We use models to observe the effect on manipulating the original, without actually having to manipulate it. A really good model will capture all of the details we need to manipulate the original, and no more. On the left we have a picture of an actual 1967 ford mustang gt, and on the right a model of that same car. Let’s say you have a child that is going through a phase where they’re really into cars. And this child wants nothing more than what his dad has – a 1967 ford mustang gt. Now, I love my kids and I want to give them everything just so I could see what marvelous things they’d do with it. However, I am not about to hand over the key to a car to my toddler. I would give them a scaled, fit for purpose version, such as the model toy on the right. It has very little in the way of extras, but it is entirely sufficient AND safe to entertain my toddler.
- A data model is a representation that describes the data about the things that exist in your domain. If you have a system – since systems operate on data – well, then you have a data model. If you’re a system integrator, you deal with data models during your integration activities. Data models come in many different representations, they express many different things in varying degrees of explicitness. Some data models capture information very unambiguously and others don’t. But no matter where your data model falls on the spectrum, you can work with it to make it better. Data models come in many flavors, and they’re not all equal. Which is best for you is going to depend on your systems requirements, and the function of the system, or component that will use that data. Here we have three examples of models many people have some familiarity with at least two of them. The dictionary is a list of terms for a particular domain of knowledge. It contains a list of terms, as well as the definitions and pronunciations for those terms. Using a representation such as this, words alongside their meaning, we can communicate about the things that exist in our domain and the meaning of those expressions, the words, is understood to those who use the same dictionary. The linnean taxonomy is an example of a hierarchical data model - it shows us the conception, naming, and classification of organism groups. It represents information in a hierarchical format, such a classification or categorization schema. Using a representation structure such as this, I can express that “this” is one of “those”.The last example is the periodic table of elements. From this we can tell that Gold has a weight and a certain number of protons… but I don’t know if 2 elements will bond, and if they will what they will form, simply by looking at this table. Per our requirements, we define a good data model to be one that captures, among other things, the semantics, or meaning, of the things that is represents in an unambiguous way. The process by which you generate a data model is something you need to consider… Especially if you need that data model that helps you meet your key non-functional requirements.
- A SoS is an appealing thing. It’s an opportunity for reuse of technology and investments. It’s a possibility for an entirely new capability to be born just by adhering to the right approach. And that approach needs to produce one key result: semantic interoperability. In a system, it's really important to model your data just to meet the general requirements, but in system of systems, if you do this properly, it can result in real, tangible benefits for years to come. But going about it in the wrong way will produce long lasting pains that are costly, especially during future integrations or as things change in your system. But this is avoidable. A system of systems is made up of many constituent systems. Each one of those constituent systems brings with it its own set of requirements that the SOS must now support. Because of this, a SOS set of requirements is actually the set that contains all of the requirements of all of the constituent systems, plus the additional requirement for semantic interoperability. As a SOS grows, so does the set of things that it needs to be capable of expressing – and while information from one system may need to be used be many other systems, this isn’t trivial 1-1 mapping of the systems interface definitions. That approach does not produce a SOS that meets the extensibility requirement, among many others. Instead, all of the systems will generate the appropriate representations such that they can meet their system requirements and the system of systems will be responsible for the creation of mathematical constructs, described using a formal language for data modeling. It is from these constructs that the constituent systems will generate their required representations.
- To achieve semantic interoperability between constituent systems, you need a new approach to dealing with your data. A SOS data shall do the following:Meet the requirements of the constituent systems. Support the overarching requirement for semantic interoperability.Allow for changes to be made to the model without requiring changes be made to the existing system and application interfaces that use it.In order to do this, we need to adopt a formal approach. The components of this approach that we are going to talk about here are the formal language, a rigorous documentation methodology, and a formal process for construction of your model.
- Transition. (to Formal Language)When we talked about levels of interoperability before, it was pointed out that we needed to achieve semantic interoperability. If I need to be able to describe the data about the things I am trying to model in a way that captures the semantics, I need a language that is up to the task: a formal language for data modeling.A formal language can be defined as a set of words over its alphabet. Sometimes the sets of words are grouped into expressions, where rules and constraints are applied for how to form the expression and allowed transformations. An expression that was created according to these rules would be deemed to be a “well formed” expression. We’ve seen that this approach produces very real results, especially in the fields of mathematics and computer science. Highly structured programming languages, such as C, are so rigorous and formal that they’ve managed to have a lot of success in consistently being able to capture the logic of programming. This can be shown by their ability to use compilers and tools to generate binary. What we need for systems of systems data modeling is very similar. If we use a rigorous and formal language for data modeling, we can achieve those same benefits. One of the key benefits is the ability to build unambiguous expressions. Ambiguities in the meaning of an expression cause errors in systems, and we can’t have that if we expect a system of systems to truly interoperate. Using a formal language for data modeling is a natural fit to satisfy this requirement. A commonly used formal language for software systems is UML, or unified modeling language. UML is managed by the OMG and as of 2000 it was accepted by the ISO as being the industry standard for modeling software intensive systems.ConclusionBy first modeling my data in a way that generates these formal representations, I can subsequently generate any of these other representations if they’re the appropriate type for my particular system, as the result of a simple mapping or transformation. All of the information is there, and it’s meaning is explicit.
- Forming expressions can be done in a handful of ways, but natural language, and ad-hoc representations in general, are prone to ambiguities. To illustrate this, consider an example. First we have a word problem, stated in in natural language and on the right, the same word problem stated in a more formal language – mathematics.. Pretend for a moment that you’re in a class and this problem is on an exam. In the first statement of the problem - on the left – you would read the following: So, where do you start? When I was given a problem such as this one to solve, I’d start by defining my variables; reading the problem carefully to ensure I didn’t miss something. Because, you know, teachers love to throw curveballs. In the end, this problem would have me walking up to the teachers desk and asking for a clarification – the ambiguities are not only present, but they result in multiple solutions if you take them account and try to solve anyhow. Can I have full credit if one of my answers matches her test key? Probably not. But it wasn’t my fault – she didn’t clearly communicate. Now, what if we stated this exact same problem using a more formal language such as logical or mathematical constructs? So, rather than state the problem as a human readable string, I state is as a mathematical formalism. Mathematical formalisms are either well-formed (explicit) or not (ambiguous). If we go about generating our expressions using a rigorously defined set of transformation rules (grammar), the results would always be something that a computer could operate on and understand;his type of representation unambiguously captures meaning. As you can see: we can’t remove the ambiguities, but they are clearly indicated – it is obvious you have multiple solutions.Having Multiple solutions is equivalent to multiple meanings, which is not ok. To achieve semantic interoperability, the meaning must be completely clear, so the formulas or expressions are required to be well-formed AND understood! After all, a statement can be syntactically valid but semantically invalid. Conclusion. formalism is a continuum; to have a sos, you need formalism because you don’t have complete control over the structure and content of all constituent systems
- The purpose of Data Model Documentation is to memorialize the decisions that were made during creation of the Data Model. These decisions include the Requirements or Use Cases that describe the functionality of the DM, as well as the Non-Functional Requirements that describe the behavior of the model over the life cycle of the system. It also records the Methodology that was used to construct the DM, as well as the resulting Model. Because in a SoS, there are many potentially competing forces that are separated in time, and by controlling organization, the effectiveness of the documentation is directly related to the degree of formalism and consistency that can be applied by different organizations at different times, over the lifecycle of the SoS.
- The third component of our formal approach was to specify a formal process.Because a SoS has many, independent organizational stakeholders that each have independent control over a part of the SoS, the processes that are used to create, and document the resulting SoS DM must enforce the high level of rigor that is required in both the model, and the documentation.______ ARCHIVE** On chart 33 second bullet, would say "end at the messages" to reinforce that the additional documentation is about the Data, not the functions, or architecture.Engineer a process to achieve the desired results.You need to engineer/architect your model such that the results from the modeling process help you to achieve the desired outcome (no ad-hoc solutions) so that you can satisfy your requirements. Don’t tweak the product of a flawed process; all you’ll wind up with is a flawed product. Change the process.Unfortunately, in the end, if you model using only these three things, it's insufficient because unless you formed each one of those using rigorous, repeatable, mathematical methods/procedures, then you really only have an ad-hoc model with a bunch of unconnected stuff in it. There are no associations being modeled so there is no context provided and the model is not semantically explicit. But you might have also noticed that when anything is ambiguously defined, or not defined at all, it’s a strike against it. Why? Because ambiguities cause errors in data modeling and for semantic interoperability to be achieved, we can’t have that. Things that we needed, but that aren’t covered by simply having enough kind of objects to be able to build properly are: the meaning of the line, how do we decided on the connections, how are we then supposed to interpret them, Depending on how your system will use data, and what type of information you’re using the model to represent, there are many ways to options, but not every option works well for all circumstances
- In the end, we want this:The ability to take those things on the left that we need to model, including the system itself!, and document their required structures and behaviors, we well as their context within the system of systems. And we will do this using a formal approach. And then, when we have our formally described and formed SOS data model, that has captured all of the information needed to ensure that the data has proper context so it can be interpreted properly by any other system wishing to interoperate with it, we can generate, from that, any representation that the constituent systems need. And because they’re all from the same root, described in the same formal language, and derived using a set of rules, those data definitions will be interoperable. And in addition to having our representations all fall out of that model, our other system documentation will also come out of this one place, because it’s all important and relevant. You have to document the system. And the data. Not separately, together.Why the language?Need to know what is well-formed, and what is notNeed to be able to extend the data model when things change (because they will!) without requiring all system elements to recompile (no N^2 integration!)Need to be able to be very expressive, but do so in a rigorous, formal, and repeatable way can encode anything, can decode anythingIf I can do this, describe my information in such a way, then I’m not integrating to a message set or a data definition per se, I’m integrating via a mediation component that performs transforms on the information in the system of systems. So when something new comes along, I don’t have to integrate to that new application, I add another transform to a mediation component. That way, I don’t have to change my application interfaces and the complexity that naturally arises from integration activities – from the need to achieving interoperability among all of these disparately developed things – it’s contained in one place, and not bleeding throughout all the other code in my system.Why the documentation?Documentation captures your decisions, your outlook, the context of the system and the data that the system operates on to produce the desired outputs/outcomesIf you’re going to integrate your system with another system, this information becomes very important to ensure that they are properly interoperatingsemantic interoperability can not be achieved without the information that captures the context of the system being modeled as wellWhy the process?Formal processesUses of Data in Systems: In the process, you see that we have structure, behavior, and context. These are all things about the systems that we NEED to capture in the SOS data model.
- A data-centric integration solution to achieve semantic interoperability is important and achievable.It is important because… One of the only things I can guarantee in a SOS is that it will change. At some point, it will. And when that change happens, rather than have your system be broken by it, why not survive it? If I architect my data in a rigorous and formal manner, and since data is what the systems operate on, then any changes in the system are easily accommodated, because they’d manifest as changes to the information present in the SOS. If the changes are made in a rigorous and repeatable way, then by knowing the rules for formation and the abstract data model that all things in the SOS come from, I can simply transform it and understand it if need be. The data will have meaning. It will have context. It will be usable and understood. Letting your system be broken by something that is inevitable seems a bit silly, especially since we can anticipate that change and accommodate it by making some intelligent architecture and design decisions upfront.Here we can see legacy, future and current systems – which is a reality – they can technically interoperate via a protocol using a common infrastructure. We know how to do that. They can syntactically interoperate by using a common data structure. But how do we accommodate the systems where can can’t change the interfaces? When they are incompatible? We need a mediation component. Achieving semantic interoperability relies on components such as this, especially since one of our requirements was that we needed to be able to accommodate change and not be broken by it (have to make changes to existing interfaces).