The Road To Here And Now …

 In my journey to create architectedfutures.net, one of the things I’m dealing with is a platform infrastructure choice. My current focus is an investigation of Drupal and WordPress. I haven’t chosen between them yet, and I believe either could do a good job for 80 percent of what I want to do, but there are definite differences in the way the job would get done, and, in the end, what gets done. So I’m digging in further, doing additional experimentation, and even toying with some concepts where I might use both. I often go back to basics, core principles, to help clarify my thinking in this process and ask myself: “What is the goal? What are you trying to do? Which is the better approach to getting there?” This post is a reflection in that vein. This post is also trying to document some history for those who are interested in following, or joining, my journey.

Objectives

My goals early on were different from what they are today, and they’ve led to experimentation with different platforms and different approaches. I don’t suggest that anyone else take the same path that I’ve followed. I don’t know how many others, if anyone, are likely driven by the same motivations or aspirations. I doubt that very many of you could afford to spend as much time as I have on the project without being forced to some form of closure, unless you are doing it as an avocation. One reason for how long things have taken me has been resources. The resources available for my project to date have principally been my time and talents. Plus, my tools and external support are all self-funded. I’ve come to rely a lot on Google and open source, community college computer science classes, and learning to configure of my own environments on my home computers. (Luckily I have a background of 35 years of professional IT experience to help find my way through the maze.) Another reason for lack of closure with my project has to do with scope creep. Some of it wasn’t really ‘creep’ so much as being distracted with multiple competing, non-aligning tasks; simultaneously tackling technical objectives and trying to address and accomplish seemingly unrelated business management processes. Some of it was expansion and evolution of vision. Some of it was just scope creep.

Tikiwiki

On the technical path, in the beginning (2005), I was looking for a platform to build a web site for Architected Futures™, the business entity I had just founded, where we could advertise our presence, and something where I could build a functional prototype of some core components of my Entity Architecture Tool Suite™ (EATS™).  (At the time I called it BEAMS – Business Engineering and Analytic Modeling System.) I wanted the prototype to support web delivery of the software product, and I researched web content management systems (CMS). Not knowing a lot about this space, and not finding much substance in the available documentation,  I decided to learn to swim the old-fashioned way – jump in the water. I bought a hosted account at GoDaddy and looked at what they had available: Geeglog, Mambo, PostNuke and Xoops. Based on a feature comparison I decided to dig deeper into PostNuke and I tried to get a feel for what its capabilities were by actually installing it, trying to configure it and looking at the code.  At the same time I continued trying to check my options based on the offerings at cmsmatrix.org. (It takes a while to sort and sift through over 168 offerings when you can’t do direct comparison by feature.) Eventually I found and isolated TikiWiki. TikiWiki had a nice suite of functions, appeared to have a reasonable approach toward security (permissions) and it had an architecture that claimed to be amenable to customization and extension; so I switched my approach to use TikiWiki as my base platform. When I had problems using TikiWiki in the GoDaddy environment, I found another web hosting company that was TikiWiki friendly.

TikiWiki worked for me for a time. I was able to develop some functional plugin extensions that integrated into the TikiWiki framework to do basic CRUD (create, read, update and display) functions against my content repository. But, as my needs became more advanced, my issues with TikiWiki grew. The platform had been useful in validating that some of my concepts could be accomplished with PHP and MySQL, but the framework was wrong for other things I wanted to do. The code was difficult to find my way around, and as is typical of most open source, there wasn’t much good documentation. If you want to know how things work, you reverse engineer the source code – often without a road map. (Thank heavens for cross-reference tools.)

PHP Frameworks

After TikiWiki, I researched and tried a number of PHP frameworks. At the time I wasn’t so much interested in a system that offered all the groupware features that were part of TikiWiki’s promise (forums, blogs, link directories, a wiki, articles, RSS feeds, etc.). Those elements were nice, but I wanted to concentrate on the core EATS™ functions. And I wanted to develop my code in a more object-oriented way. I wanted to drive my processing using a document-centric, message-based architecture, and I wanted to move to PHP5 and OO development. So, rather than looking for a new “web solution” I tried to concentrate on something that would give me a structured framework for development of a CMS using PHP5; something that I could leverage so that I wouldn’t need to build everything from scratch. By early 2007 I had done research into a number of offerings and had completed some experimentation on ModX, the Zend Framework and  Symfony; all of which looked initially appealing but none of which were fully satisfying. I was trying to do something that wasn’t aligned well with what other people were designing these packages for, and making the different goals play well together wasn’t going well. In the end I gave up on trying to fight someone else’s concept of how I should construct a web-delivery system and I decided to go ahead and create a proprietary platform. That worked, and I made further progress on advancing the EATS™ software using my own PHP framework.

Java

While I was developing prototype code for the content repository in PHP, I was also developing a web framework to host and deliver the core code, and evolving conceptual designs and specifications for the higher level EATS™ functionality. Once I had certain core concepts prototyped in PHP, I then started moving them to a Java implementation, experimenting with both desktop Java and web delivered Java based on Apache Tomcat and Servlets. For good measure I even worked with C# and Microsoft’s .Net technologies. I wanted to satisfy myself that the architecture was implementation technology agnostic. By building it, or at least critical pieces, in PHP, Java and C# I knew it was more than just wishful thinking. In addition, during this time period, I spent some time studying and experimenting with GIS technologies, discovering their associated implementation requirements.

For a number of reasons, once the Java development started rolling, Java became the primary implementation vehicle for the evolving EATS™ software and the PHP code got sidelined. (It gets tough to keep focus on that many balls in the air at the same time.) Over the last year or so, based on what I’m trying to do with EATS™, the Java  exercise has moved toward Eclipse  with investigations of the Rich Client Platform (RCP), OSGi, and the Eclipse Modeling Framework (EMF), some of which potentially re-introduces platform dependencies, for different, to me more legitimate, reasons. Java is also the infrastructure platform that makes the most sense from a commercial development basis.

(More on page 2, below)