Part 2, The Specification

Strategy

My core strategy for achieving my long-range goal is to create a collaborative presence on the internet that can be used to publicize my thinking on this subject and to invite participation in the process from like-minded individuals. I expect to lead the initial discussion until, hopefully, a critical mass of interested people become involved in the process. Over time I would like the group to become self-governing and assume a life of its own. That would indicate validation and long-term viability for the proposed concepts and methods.

Given the somewhat esoteric nature of my objective, the online community I am planning is not anticipated to rival Facebook or LinkedIn. Scale should not be a major problem. However, with the help of the internet, it will hopefully attract an audience of people who share a serious interest in this specialized topic. Providing support for multiple, concurrent, asynchronous dialogs across an international population of users would be a nice problem to have.

The target membership for my online community includes:

• Enterprise architects – because they as a group probably have the most familiarity with the issues my proposed tool suite is meant to address, and they might enjoy the most benefit as early adopters of the technology,
• Process engineers – because they are key practitioners in the use of engineering and computer-based methods and models as applied to business problems,
• Futurists and planners – because of their focus on hypothesizing realizable future environments and evaluating alternative scenarios to enable their creation,
• Social Scientists – because I’m interested in the applications of my ideas as a tool for the study of society and for evaluating alternative futures,
• Business owners and executives who might be interested in leveraging the concepts and the technology to organize and manage increasingly complex operational and legal environments,
• Software engineers and developers who may be interested in collaborating on some aspect of the tool suite development,
• Business analysts, data modelers and information architects who may be interested in collaborating in the development of one or more of the information models used in the methodology,
• Entrepreneurs who may be looking to monetize some aspect of the concepts,
• Researchers, students and the intellectually curious who are otherwise interested in the subject matter.

Short-term Goal

My short-term goal is to launch architectedfutures.net as the enabling technology to provide the means to communicate the vision and enable participation in the community. There are two major parts to this effort, one is social and cultural, the other is technical.

The social and cultural part has to do with the design and configuration of the community. That is the most important part and it is occupying a lot of my time and thought process. But that isn’t the main thrust of what I’m blogging about on this site. For those who are interested in following that train of thought, I suggest you follow some of the resources which I’ve listed at the end of this post. I’ve found them very helpful. Of course, you’re welcome to follow this site also, since I will continue to provide some of that content as background to my site building activity. I would also invite you to join our community once we get our technology in place. I’d enjoy conversing with you about how the tool suite can be adapted to help architect community processes.

The second part of the task is technical – providing an appropriate technology platform for my planned community. And that process is the main focus of this blog. Ideally I want to evaluate my technology choices against three stages in the life-cycle of the community:

• The launch stage – where I may start as the only member of the community and the technology platform may serve primarily as a personal blogging and content staging platform. (Here we are! Almost.)
• The early growth stage – where membership builds over time and the technology platform needs to support involvement by a growing community of people interested in active involvement and interaction concerning the content of the site.
• The mature community stage – where the community evolves to a self-sustaining and self-governing community of practice around the core concepts and mission established for the group.

What is critical at the beginning is the ability to fully support the requirements of the launch stage and evolve gracefully to support the early growth stage. (Note. I don’t consider this blog as the launch. I consider it to be pre-launch. Launch will be the first use of the community site.) An ideal platform would continue to evolve gracefully to support the mature community; but, if needed, some platform transition may be acceptable at a later point if a single platform does not work through-out the life-cycle.

Decision Matrix Adjustments

In part 1 of this series I talked about using a Decision Matrix to define an objective scoring and evaluation of the alternative systems against my needs. This gets complicated if I am evaluating each system with respect to a set of requirements that varies over time as the community goes through different developmental stages. Here are two general solutions to the problem:

1. If the transitions are expected to happen in rather rapid sequence, and there is a strong desire not to go through any form of platform infrastructure conversion along the way, then a single platform that is best suited to the needs of all three stages is probably the best choice. The decision matrix should be built with all requirements for the full life-cycle included. The “Go/No-Go” criteria needs to be established in terms of needs for the most demanding period.
2. If the stages are expected to last for a while and the resource availability or demand is expected to vary considerably, there may be time and/or reason to consider the option to plan a migration of platforms as the community grows. If the move only involves something like changing hosting arrangements, it should not be a big deal. That would be considered normal process and not the type of change I am talking about here. If the move might require changing the software platform for the community, it is a risky proposal that requires careful consideration. But it may still make sense. The reason for a careful selection process up front is to anticipate our long term needs and avoid the need to switch platforms later if we can.

One reason to consider the second alternative is if there is a strong desire to weigh requirements differently between what is needed for the different growth stages for the community. In addition, there may be a lot of requirements that have high demand in a mature community, but they are superfluous, or even in the way, during the launch or early growth stages. One way to determine this is to derive scores and check the alternatives on a stage-by-stage basis.

For each stage of community development, only score the requirements that matter for that stage. Features (requirements) that are not needed for a particular stage, features that get in the way and features that drive up costs and administrative overhead without adding value to the community at that stage, should be dropped or “weighted” with a zero multiplier.

Then compare the alternative’s weighted total scores on a stage-by-stage basis. If one alternative wins on all stages, the issue is moot. If one alternative is a strong leader for the longer term, but has slight disadvantages during startup, you may want to put up with the start-up problems and avoid the conversion problems. However, if there is a clear and strong advantage to one alternative for start-up and another alternative for the longer term, you may want to consider both solutions and start to think about how a transition might be able to be accomplished. Remember, you have to be able to get past the start-up phase before you need to face the transition problem, and you probably don’t need the extra overhead of fighting a solution that is too cumbersome for the tasks you want to accomplish in the early period of community development. A transition after you’re established may be a worthwhile approach.

Note: WordPress has some very nice advantages in this regard. One can easily start out with a free or low cost wordpress.com blog (such as this one), migrate to a blog using wordpress.org components, and then convert that site to a more full featured community site over time by adding BuddyPress and related plugins to the base site. All using the same technology framework.