Open Source / Open Architecture / Open Notebook

Announcement of policy change regarding management of content on this web site.

The purpose of this blog post is to announce a shift in strategy in the development of materials relative to EATS and Architected Futures. EATS has, of late, been developed to be an open source, open architecture software development effort. However, the totality of what I have wanted to do with Architected Futures has not been approached as fully public material. I now think that, while that may, or may not, have been appropriate when I started this web site, it is not sufficient going forward.

The full details of that can be left to a separate discussion. But let me provide this rationale, and warning for potential readers:

• My original intent was to have three tiers of information. Public, Internal and Restricted. Public is what everyone (including search engines) would have access to. Internal was a classification meant to be provided to a Architected Futures™ Community of Practice (AFCoP). (Again, separate discussion.) Restricted was reserved for content required to manage the site. It would be available to site administrators and moderators on a need-to-know basis.
• While the site has a separate facility for differentiating and managing published and unpublished content, one use of the Internal classification was to allow the publication of notes and discussion drafts as published, but only to the internal Architected Futures™ Community of Practice (AFCoP). That material can be thought of as the notebook content in the title for this post.

Well, at this point there is no Architected Futures™ Community of Practice (AFCoP), unless you define it to be a community of 1. However there is a growing population of people working on concepts and facilities that are very closely aligned with the ideas being developed here, and a growing criticality of need for the fruits of that effort, on a collaborative basis, to society as a whole. Furthermore, my own ideas around the EATS framework have reached a point where I can finally see and discuss it as a complete technically feasible whole, whose architecture I feel comfortable engaging on with others in a reasonable rigorous fashion. To do that, I need to be able to share content that, until now, hasn't been prepared in a manner that is fully ready for public consumption. The way a project team would share notes about partially worked out concepts, so they can gain the benefit of additional viewpoints from other team members, on the way to developing solutions. It's called collaboration.

That last part doesn't mean I am going to uncover and unveil any magic answers to the world's problem, or technical miracles. But simply that before I had a system idea that I thought might work, and now I've finally carried it to a prototype development level where I've convinced at least myself that it's viable, and I have a reasonable concept of how it should be put together.

The Warning

The warning is related to the second bullet point above. Most of the time in today's competitive environment, we think "first to market" is the key to the kingdom. So, we work out "secrets" in proprietary labs, to be able to patent them, and become rich. And, it's possible that the key to solving a very thorny problem might be half-understood by one research lab, and understood from a different angle by another. If they could just see each others work, they would both cry out "Eureka!" But they can't, and they work afraid that the guy next door will publish before they do. So they hold their cards close to their vest. With government grants and funding, this changes a little, but not that much. There's still a lot of "secret" and "NDA" stuff happening, and folks make a lot of money on the back of publicly funded research. 

That's okay by me, but it really isn't helping the planet, or the human race, deal with some big problems. It even worked well to spur innovation for a while, but my personal belief is that it's holding us back from dealing with the complexity and degree of technological acceleration we are encountering in the 21st century, let along what is going to be happening as that acceleration continues to increase exponentially. It simple economics. Its not velocity, its acceleration . And like compound interest, it grows exponentially.

Now, the warning:

When I post my notebooks on the web for all to read and share: Some of the content is in very rough note form. And, my notes are full of stuff that means something to me, but are gibberish to others. I have been using, and will continue to use the web content as a warehouse for my notes. It is my codex, using web pages instead of hand-written pages to compose the notebook. Some of that content will have obvious editorial marks identifying it as notes, or preliminary. Other content may not be so obvious, but the material on those pages should still make sense, but it is not for the casual reader.

One thing that has plagued me through my career in systems engineering is that I always thought: if I just had the right tool put together the right way, I could explain this stuff to others, and they could use a comfortable trail through the wilderness that they were comfortable with to understand it. Kind of like taking your own style of tour through a national park. You can hike the back woods wilderness trails, or camp in a cabin for awhile and just soak it in, or drive through with your car, or take one of the all day tours, or just listen to the range at the visitor center. Lots of ways to appreciate what is there.

Well, at this point I believe I've finally build a design model of what that tool really needs to do, and how it needs  to work, in its essence; but I don't have a fully functional version of the tool. I have a demo, a prototype, and some of that is in pieces, not integrated. That' the current state of the part called [Freelinking: node title “afcore:eats” does not exist]. As [Freelinking: node title “afcore:eats” does not exist] comes together and matures, it will be easier to share and collaborate around this material to solve problems. In the mean time, I'm doing my best to both share as much as possible, and segregate stuff so different folks can read this material from different perspectives, and make immediate use of what they can glean, to the extend they care to make use of what's here.

Be careful with the content as you read it folks, some of it is obtuse and possibly half-baked. This largely happens in things like slide aggregations, and various "notebook" documents. 

My approach is guided by the following:

• If I was working in a lab or on a development team, would I want these notes open and accessible to the other members of my team, or would I hold them back because they would just confuse everybody. In that case, I hold it back. If they would confuse some folks and help others to understand and make progress, they get published. That later bunch of stuff is what I'm talking about here.

The primary thing to keep in mind in terms of that second set of material is a conceptual shift from EATS as a tool for "enterprise architecture" to the software suite as a tool intended for managing the architecture of virtually any form of system. A major problem that I have worked on through my career as "an architect" of systems, is the problem of how to create and manage what we always called "living documentation" for the system being developed and maintained to assist in the operation of the enterprise. Project team members need to be able to participatively share in the creation, access and maintenance of that documentation, and it needs to be a dynamic facility. This web site is my current attempt at a system to do that. It is integral to both my methodology and tool suite in that sense. It should be and needs to be a view port over the whole encyclopedia of elements that are directly associated with EATS and Architected Futures. Sometimes that means it may require Q&A for comprehension. 

Policy

For the new policies associated with this post, please see this material.