Part 2, The Specification

Image of bicycle specificationThe next step in this community of practice software evaluation is to define my goals, and to brainstorm the initial requirements to achieve those goals. Not everything in this series of posts will follow this top-down, linear path; but starting out with this material will give context and add structure to the evaluation process.

Long Range Objective

My long-range objective is to explore and develop architectural engineering methods as part of an automated tool suite to manage the evolution of future environments.

Ultimately this is a journey, not a destination. You do not need to grok that statement or identify with this goal to benefit from following along with this series on my Drupal-WordPress evaluation process. Your goal might be very different from mine. To get the most benefit from this series your goal should have something to do with creating and maintaining an online community. If so, you can probably use a lot of what I will discuss.

If the goal that I’ve stated above is meaningful to you and interests you, you may also be interested in following, or joining, the online community at architectedfutures.net once that site goes on the air. You can use the Contact page to send me a note and I’ll keep you informed when that happens.

If the goal is just gobbledygook to you, here is an attempt to translate:

I view architecture in a general sense.  My definition of architecture is:

The art and science of designing synergistic structures in a manner which achieves utility, durability, and delight to its users. The architecture of an object is the manner in which its components are assembled into a unified whole designed to satisfy a cohesive purpose. Architecture as a practice is the art and science of designing structures, systems of composite elements, into unified wholes to achieve that purpose. The quality of an architecture can be measured by its social relevance in terms of utility and satisfaction of function, its soundness of engineering and durability, and its esthetic characteristics and the ability to bring delight to its users.

There is architecture to buildings, towns and cities; but there is also architecture to software systems, planes, trains and automobiles. There is architecture to social systems and governments. There is architecture to all composite systems where the parts act together as some form of unified whole for a purpose that is derived from the whole, not from the individual parts.

Paraphrasing Wikipedia architectural engineering is the application of engineering principles and technology to the design and construction of an architected system, an architected entity or an architected element.

So, my goal is to design and build a suite of software tools which foster taking a holistic view of architected entities, and applying engineering principles and methods to help manage change in, and on, those entities; to move them (evolving them) to achieve a more desired or more beneficial future form. In theory, these tools might be used to manage the evolution of a software system, a business entity, an ecosystem or a society. All of which might be considered to be architected entities.

I’m a futurist. I’m fascinated with what will be and what can be, and how things can be shaped or steered so that certain outcomes can become more likely, goals achieved, problems avoided, etc. As a software developer you build systems today for use by people to help them perform functions more effectively tomorrow. As a planner, designer or architect, you create a product to change an environment to operate in a different, hopefully better, manner than the way it was operating without your changes. Your product is composed of components that need to work according to certain parameters to meet your design objectives. And your product operates within, is impacted by and changes the environment it is placed within. The scale of the problem of understanding the relationships and complications of these issues boggles the mind for most products (processes, organizations, …) of reasonable complexity in today’s world; and the impact of not understanding some potentially critical relationships can be disastrous. Bridges fall, cars crash and financial systems collapse. I believe there is a need for good tools to help with this task. That’s a need I would like to help fill.

If that’s still gobbledygook, suffice it to say that my goal is to build a software product to help people make better decisions about things that impact how the future will unfold.

One thought on “Part 2, The Specification

  1. Pingback: Part 4, Decision Time | Building Architected Futures™

Share your thoughts ...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s