Re: [Non-DoD Source] Re: [cti] The Adaptive Object-Model Architectural Style

[Jerome Athias <athiasjerome@gmail.com>]

First thing first, Welcome!

and thanks for your feedback.
I do agree.
I guess so far we used "A good plan today is better than a perfect
plan tomorrow...." - Planning quote by George S Patton
And definitely, we are trying to (and making good progress) on the
documentation.

/JA


2015-11-13 17:47 GMT+03:00 Bohling, James T CIV JS J6 (US)
<james.t.bohling.civ@mail.mil>:
> CLASSIFICATION: UNCLASSIFIED
>
> Hi I am new to this committee.  I am very interested in the progress of this set of standards and am going to try to jump in to make a contribution.
>
> Based on below, I agree with all comments as they each have merit, but I mostly agree that simple description and approaches should be used first.
>
> I am seeing comments that suggest this domain is difficult; ref: "Our standard has a lot that's hard to explain" and " dealing with a complex domain".  I do believe there are concepts and abstracts that will be tough to deal with but we should explicitly lay out what those complexities are; we may just find that they are not as complex as rumored.  They are rumors or speculative until we document them.  By documenting the complex abstracts and subsequently solving them, we will also reduce the chances that the domain will generally always be viewed or perceived as a complex domain, just because it has always been stated as such.
>
> Documenting the challenging portions will also enable us to gauge our own abilities to deal with them correctly.  In turn, we may seek additional knowledge or support to tackle the challenges or we realize it is not as difficult as perceived.
>
> V/R
> - James
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> James Bohling,
> Joint Staff J6, DD Cyber and C4 Integration, Chief, Cyberspace Interoperability Data and Services Division ☎ 757-836-8079 NIPR:james.t.bohling.civ@mail.mil SIPR:james.t.bohling.civ@mail.smil.mil
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
> -----Original Message-----
> From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jerome Athias
> Sent: Friday, November 13, 2015 9:17 AM
> To: John Anderson
> Cc: cti@lists.oasis-open.org
> Subject: [Non-DoD Source] Re: [cti] The Adaptive Object-Model Architectural Style
>
> All active links contained in this email were disabled.  Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
>
>
>
>
> ----
>
> sorry for the others if off-topic.
>
> Remember that a software is good only if it satisfies the users (meet, or exceed, their requirements).
> You can write 'perfect/optimized' code. If the users are not satisfied; it's a bad software.
>
> Then,
> "If you can't explain it simply, you don't understand it well enough.", Albert Einstein
>
> Challenges are exciting, but sometimes difficult. It's about motivation and satisfaction.
>
> There is not programming language better than an other (just like OS); it is just you that can select the best for your needs.
>
> I did a conceptual map for the 'biggest Ruby project of the internet'
> (Metasploit Framework), it's just a picture, but represents 100 pages of documentation.
> I think we could optimize (like for a maturity model) our approach of resolving problems.
>
>
>
>
>
>
>
>
>
> 2015-11-13 17:02 GMT+03:00 John Anderson <janderson@soltra.com>:
>> The list returns my mail, so probably you'll be the only one to get my reply.
>>
>> Funny, I missed that quote from the document. And it's spot on. As an
>> architect myself, I have built several  "elegant" architectures, only
>> to find that the guys who actually had to use it just. never. quite.
>> got it. (sigh)
>>
>> My best architectures have emerged when I've written test code first. ("Test-first" really does work.) I've learned that writing code--while applying KISS, DRY and YAGNI--saves me from entering the architecture stratosphere. That's why I ask the architects to express their creations in code, and not only in UML.
>>
>> I'm pretty vocal about Python, because it's by far the simplest popular language out there today. But this principal applies in any language: If the implementation is hard to explain, it's a bad idea. (Another quote from the Zen of Python.) Our standard has a lot that's hard to explain, esp. to new-comers. How can we simplify, so that it's almost a no-brainer to adopt?
>>
>> Again, thanks for the article, and the conversation. I really do
>> appreciate your point-of-view, JSA
>>
>>
>> ________________________________________
>> From: Jerome Athias <athiasjerome@gmail.com>
>> Sent: Friday, November 13, 2015 8:45 AM
>> To: John Anderson
>> Cc: cti@lists.oasis-open.org
>> Subject: Re: [cti] The Adaptive Object-Model Architectural Style
>>
>> Thanks for the feedback.
>> Kindly note that I'm not strongly defending this approach for the CTI
>> TC (at least for now).
>> Since you're using quotes:
>> "Architects that develop these types of systems are usually very proud
>> of them and claim that they are some of the best systems they have
>> ever developed. However, developers that have to use, extend or
>> maintain them, usually complain that they are hard to understand and
>> are not convinced that they are as great as the architect claims."
>>
>> This, I hope could have our developers just understand that what they
>> feel difficult sometimes, is not intended to be difficult per design,
>> but because we are dealing with a complex domain and that the use of
>> abstraction/conceptual approaches/ontology have benefits
>>
>> Hopefully we can obtain consensus on a good balanced adapted approach.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2015-11-13 16:24 GMT+03:00 John Anderson <janderson@soltra.com>:
>>> Jerome,
>>> Thanks for the link. I really enjoy those kinds of research papers.
>>>
>>> On Page 20, the section "Maintaining the Model" [1] states pretty clearly that this type of architecture is very unwieldy, from an end-user perspective; consequently, it requires a ton of tooling development.
>>>
>>> The advantage of such a model is that it's extensible and easily
>>> changed. But I'm not convinced that extensibility is really our
>>> friend. In my (greatly limited) experience, the extensibility of STIX
>>> and CybOX have made them that much harder to use and understand. I'm
>>> left wishing for "one obvious way to do things." [2]
>>>
>>> If I were given the choice between (1) a very simple data model that's not extensible, but clear and easy to approach and (2) a generic, extensible data model whose extra layers of indirection make it hard to find the actual data, I'd gladly choose the first.
>>>
>>> Keeping it simple,
>>> JSA
>>>
>>>
>>> [1] The full wording from "Maintaining the Model":
>>> The observation model is able to store all the metadata using a
>>> well-established mapping to relational databases, but it was not
>>> straightforward for a developer or analyst to put this data into the
>>> database. They would have to learn how the objects were saved in the
>>> database as well as the proper semantics for describing the business
>>> rules. A common solution to this is to develop editors and
>>> programming tools to assist users with using these black-box
>>> components [18]. This is part of the evolutionary process of Adaptive
>>> Object-Models as they are in a sense, “Black-Box” frameworks, and as
>>> they mature, they need editors and other support tools to aid in describing and maintaining the business rules.
>>>
>>> [2] From "The Zen of Python":
>>> Caution-https://www.python.org/dev/peps/pep-0020/
>>>
>>>
>>> ________________________________________
>>> From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf
>>> of Jerome Athias <athiasjerome@gmail.com>
>>> Sent: Friday, November 13, 2015 5:20 AM
>>> To: cti@lists.oasis-open.org
>>> Subject: [cti] The Adaptive Object-Model Architectural Style
>>>
>>> Greetings,
>>>
>>> realizing that the community members have different background,
>>> experience, expectations and use of CTI in general, from an
>>> high-level (abstracted/conceptual/ontology oriented) point of view,
>>> through a day-to-day use (experienced) point of view, to a technical
>>> (implementation/code) point of view...
>>> I found this diagram (and document) interesting while easy to read
>>> and potentially adapted to our current effort.
>>> So just wanted to share.
>>>
>>> Caution-http://www.adaptiveobjectmodel.com/WICSA3/ArchitectureOfAOMsW
>>> ICSA3.pdf
>>>
>>> Regards
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
> Caution-https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> CLASSIFICATION: UNCLASSIFIED