The Road To Here And Now …

Scope

Over the last year or so the magnitude of this effort has grown larger, and I have been impressed by a need for change in my operational tactics. There is a limit to what I can or should do on my own. Plus, there are related but undeveloped dimensions that I want to explore. Some of these things are beyond the scope of software development. In the beginning the central driving focus of my efforts was the EATS™ software. I didn’t want to spend my energy selling it. I didn’t want to focus on convincing others of its value. I inherently knew its value. I wanted to build it, to demonstrate it. I was convinced of its utility and I wanted to create a usable implementation that could be shared.

Over time that mental model has changed. EATS™ as a tool is still there. But I think that the utility of EATS™ extends beyond the tool. EATS™ is also about an approach to solving problems in a particular domain, although the full extent of that domain is more difficult to define. I used to consider EATS™ to be methodology agnostic. It can be used with most or all the process management, enterprise architecture and software engineering methodologies that I am familiar with. But EATS™ isn’t methodology agnostic. Fully buying into the use of EATS™ also means buying into an EATS™ method of approaching problem solving – a methodology in its own right. That methodology doesn’t compete with other methodologies. It’s complementary and probably acts as a catalyst to make the others more productive. But using EATS™ also involves buying into a longer-term  discipline to documentation and analysis techniques if you want a good return on your investment. That approach in conjunction with some EATS™ techniques is a methodology.

Domain

On the domain issue EATS™ conceptually started as an enterprise architect’s tool-suite for addressing enterprise architecture management problems: understanding flows; synchronizing and validating models; tracing functions to requirements; mapping concepts to logical design to implementation details; managing a dynamic encyclopedia of elements and relationships… It started in the Information Technology (IT) domain as a tool to make sure that the IT development architecture mapped appropriately to business requirements.

There is another intersecting design principle involved with EATS™ that has grown in importance over time: abstraction layers. Abstraction layers are typically used to hide implementation details of lower level systems. But what they create is a series of layers, at different levels of abstraction, of the same conceptual system; like Russian dolls, one nested inside the other. You can use the layers to hide lower level implementation details. You can also use the higher layers to give contextual specification to the environment in which the lower level needs to operate.

One way to gain some assurance that the IT model for an enterprise is correct involves developing some degree of a model of the business enterprise environment within which the IT systems run. A lot of times we do this mentally. What that means is that we depend on business subject matter experts (SMEs), people who have this mental model, to check the system requirements and certify that the requirements are in accord with business needs and objectives. With EATS™ it is possible to do part of the validation physically (by building business entity elements into the architecture repository). Then, exception reports produced by the system are reviewed by the SMEs. This opens up a whole new realm of utility and the ability to audit and verify more complex models, in less time, with fewer resources, and higher confidence in the results.

The same modeling and analysis is also useful to a  business for purposes of managing efficient business processes, independent of using it to detail, analyze and help with the design of the IT systems that support that business. And, from a process perspective, there is no need to change the EATS™ software to allow this new application. Continuing the iterative cycle: constructing and validating a model for a business enterprise involves developing some form of model for the environment in which the business operates. One might develop a model of standard practices within the industry, some form of market model, a supply chain model, etc. Models cascade on models, cascade on models, cascade on models. EATS™ doesn’t really care what you are modeling and analyzing – what it cares about is how the components interrelate, the significance of the relationships and how you approach the modeling effort.

Opportunities within the subject domain open up considerably when you take this perspective, and the benefits grow too. A multi-million dollar IT investment that is validated to conform to business needs and objectives has less risk of going wrong and more assurance of utility over time. If the business needs and processes that the system supports are also validated in terms of industry patterns and trends, the risk is further reduced and the time horizon of utility is increased.

What happens as you expand the layers of models is that the complexity and scale of the overall model and modeling effort grows. What can happen, faster in the “old days” than today, is that you run out of computer resources to configure and execute your models.  That issue is nowhere near as delicate as it was when I started in this business. My watch now has more computing power than my first PC. Your desktop computer (assuming it is reasonably up to date) probably has more computing power than the entire data center where my first business applications executed. (Being able to “wrap your head around” and manage such models is a subject for another story.)

Community of Practice

These are important shifts in thinking and approach that I want to explore. I want to put forth my ideas and see how they resonate with others. I want to see how other people’s ideas and insights might confirm or refute what I am thinking and doing. Plus, I want to open up and share what I have done so far in the development of EATS™ and invite others to take part in the process. To that end, I’ve shifted my strategy for how I’m approaching my work. The new strategy will use open collaboration through a community of practice framework. To support the community of practice I need to prioritize the development of a community website. This time the primary focus of the web site isn’t to act as a framework to deliver the EATS™ software product. The primary purpose of the web site is to provide a medium of collaboration for a community of people who wish to engage in discussion and development of the concepts. Of course EATS™ is still a central element of discussion and a functional prototype supporting the community is still an objective.

That brings us back to the opening paragraph of this posting and Drupal and WordPress. Drupal and WordPress are my two candidate platforms for building the community of practice web site. In the case of WordPress the software suite that accomplishes most of the social interaction functionality is a component called BuddyPress. BuddyPress operates on a WordPress base. In the case of Drupal the site building gets a little more complicated. That’s what I plan on talking about as we go forward.

Hopefully, if you’ve followed me this far, you’ll be interested in reading about how I approach resolving the choice.

If you are interested in the concepts and discussion about Architected Futures™ and/or EATS™ but less so about how the web site gets built, drop me a note on the Contact Page and I’ll let you know when the community website gets launched. You can join us there for the full discussion as it unfolds.