I have been researching the mobile applications space looking for a good (it is subjective, I know) technology stack that meets the following wish-list:

• Future proof (to some extent) – shifting in device types, geometry and OS-es will not render the stack unusable in over the next couple of months, maybe a year or two. This point also includes support for a variety of devices based on their use and market share.
• Does not require a steep learning curve for most development shops – existing skills available (in abundance) in the IT industry today would be able to match the proposed stack without much skills update, preferably only learning new APIs and not a whole new language and programming paradigm.
• Does not cost an arm and a leg – at least it is free to start developing and testing (simulator and device) and remains low cost (subjective again) going forward
• Plays nicely with current technology stacks – depending on the technology stack available in the environment where the mobile applications will be deployed – in my case this would be Java/Spring/Adobe Flex.
• Fast and Easy prototyping and demo – in other words a single person in a few weeks (weekends) can produce a working prototype or demo to sell the idea of the application.
• The end result is top-notch – it takes advantage (perhaps not fully) of the device specifics and features that make an application pleasant and usable from an end user experience point of view.

There are many good articles about the comparison of native and Web applications, like this one: Mobile apps choices: Native Apps vs Web Apps.

During my researches however, I came to like the technologies that are somewhere in between native and Web applications. It is a blurry, gray area for applications. They are developed like Web applications, but look and behave like a fully featured mobile application.

Two of these favored technologies are PhoneGap and Appcelerator/Titanium. Another good article on these two are here: A deeper look at appcelerator and phonegap.

Another intriguing technology is from the Mono team – MonoTouch and Mono for Android. It is also an inbetweener type, although more on the native application side, reusing a great deal of C# .NET skills for development. Still thinking through the future-proof valuation of this stack.

In the meantime, the search for the best technology stack for mobile applications continues…

Enterprise-wide initiatives require enterprise-wide tools – Excel!?!? Like it or not, Excel is the universal tool in many places to

• collect data
• share information
• organise information
• and more…

Is it a good thing, or is it curse? Most likely it is not good, but it is not going to change for a while.

But not all is lost, there are ways to leverage the content from spreadsheets and reuse them elsewhere (other than Excel) or turn them into something more informational.

1. Some of the tools provide with direct Excel import/export functionality.
2. Since the 2007 version, Microsoft (Office) Excel offers an XML import/export function (not the save as .xlsx), where a user defined XSD (Excel schema) is mapped to columns on a sheet. The XML files can subsequently be transformed through XSLT to other formats for interacting with various tools.
3. It is rather easy to extend Excel using Visual Basic scripts (macros) to generate the output that is easily or directly imported into various tools.

The next blog entry will be on this last (3) option – how to use a macro in Excel to generate content for visualisation in yEd.

Countless times the Enterprise Architecture (EA) discussions end up in debates over some analogy trying to explain what EA is. The analogy often used is traditional architecture.

I am not a great fan of the traditional architecture analogies myself, by the way I feel the same way about the use of car manufacturing. These analogies often fail to meet the level of abstraction on the two sides of the analogy, and the conversation soon becomes a debate which architect designs the brick, or the piping; which one is responsible for a specific floor of a building, or is it the whole building, maybe the whole city? and it goes on and on…

At the same time, I have to admit whatever helps to get on the same page with a team of people will just work fine. To help the situation I have looked for materials on the Web to support the analogy. I have found the following PDF (size warning: 3.7MB), which I thought was brilliant in itself – it is a great piece of work (competition entry) from a team. It also supports the breadth and depth of architecture that can be related to the various IT architecture disciplines, including EA.

The link to the document is here. Unfortunately the original document is not available at the original location anymore, which was at http://udcompetition.uli.org/ under the 2004 archives. More designs can be found in more recent archives, under the results page.

Recently I have started using yEd, a free (not Open Source) graph editor, to produce IT Architecture diagrams.

It is written in Java and runs on many platforms: Linux, Mac OS, Windows… It supports a the graphml file format describing graphs. It provides the most essential visualisation features including

• Boxes
• Arrows between boxes
• Boxes in boxes

The real highlight of the product is the sophisticated layout algorithms it offers. The other key feature is the export of graphs in a variety of formats including: SVG, PDF, JPG, etc

What is it good for?

I am planning to automate the production of diagrams for IT Architectures. This application will not replace sophisticated drawing tools due to the limited graphics capabilities, but the plan is to use it for generated diagrams anyway. Where the tool excels is the variety of layout strategies and algorithms it offers to arrange the diagram elements on the canvas, and it can deal with a large number of elements and produces impressive results.

Why not use Visio?

Although it does not offer the same level of sophistication and representation as Visio, it has the advantage of automating the production of diagrams. I am looking at a variety of input sources and driving those through “good old” XSLT to get the result – graphml file. In fairness Visio also supports XML, however the graphml format (including the yWorks extensions) is far less complicated to process. A big advantage over Visio is the support for ‘box in a box’ structures, in other words containment. Visio can only support ‘box over a box’ which is just an imitation of the structure.

The purpose of the Systems Ontology is to provide a framework, in the form of an ontology, for capturing system details resulting from systems analysis.

The Systems Ontology is composed of three distinct parts:

• SystemThing holds the core concepts of a system – not to be changed
• SystemSpace is a definition of categories applicable to different concepts describing specific systems – should change rarely as the understanding of the different types of systems evolves
• System is the place for the instances of specific systems – may change regularly as the analysis and understanding of specific systems progresses.

The following diagram is a representation of the different elements in each part.

Core concepts and Spaces
Core concepts define the fundamental building blocks for the Systems Ontology in a set of abstract classes of mainly two types: Thing and Space.
Things describe the different aspects of a system on very high abstraction level (meta-meta in this case).
Spaces provide further refinement for the different aspects of a system.

Structure
The structure of the system is described in abstract sub-classes of StructuredThing. The structure defines the relationships between concepts, it defines what form (in terms of graphs) of construct can be built. Constructs can be for example: chain, ring, tree, net, a combination of these or any other formation.

Specific structures are defined inheriting from the StructuredThing abstract class, making StructuredThing a collection, a container of various types.

An example structure: ComposableThing has two slots, has_part and is_part_of (both are each other’s inverse), since has_part is a multi-value, is_part_of a single-value slot referring to instances, the structure for ComposableThing is going to be a tree.

Category
Categories are defined in the CategorySpace, which holds a hierarchy of categories underneath. CathegoryThing enables instances of a system elements to reference multiple categories from the CategorySpace.

CategorySpace is a bit unusual as far as modelling categories goes. Usually there is a meta-model for describing the characteristics of a category on the meta-model level then each category is an instance in the model often in some form of relationship with other categories.
In this case, a different, perhaps unusual approach is taken when categories are defined as classes and sub-classes of classes. This will allows to build a hierarchy of categories and use the class name for the name of the category, which should be sufficient as no attributes are necessary.
There is one more twist, instead of assigning a class (category) as a superclass to the categorized class, the CategorizedThing defines a slot with the value type of a class, in other words the category is defined as an attribute (slot).

This approach allows to define the categories in the meta-model in a hierarchy and still use them as an attribute in the model.

Life-cycle
The notation of life-cycle makes the concepts “alive”, in other words, it represents the time factor.

Individual life-cycles are captured in the LifeCycleSpace as sub-classes. Life-cycles consist of states, these are captured as instances of a life-cycle class in the ontology. LiveThing enables the system instances to reference individual states and other related instances – behaviour and quality (details in the next section).

Note that life-cycles are not described as proper state-machines in this ontology. There is no notation of events or state transitions other than registering the preceding and following states for each state instance.

Behavior and Quality
The following assumption was made: Only “living” things (ie concepts with life-cycle) show characteristics of behavior and qualities.
Based on this assumption, behaviour and quality details can be registered to any LivingThing.

Behavior and Quality are two concepts represented in the ontology in a similar fashion.
BehaviorSpace consists of sub-classes, where sub-classes are considered as categories of behavior. These categories can serve as a mechanism to group, qualify, arrange the long list of different behaviors a system may have.
Specific behaviors are captured as instances of a Class from the BehaviorSpace.

Qualities are represented the same way, where categories are sub-classes of the QualitySpace and specific qualities are instances of a class from the QualitySpace.

System instances
The root for capturing specific system instances is SystemSpace, it inherits a set of abstract classes (LivingThing and CategorizedThing) describing a system.

Besides creating instances for system elements a few other types of instances will be created along the way including: life-cycle states, behaviors and qualities.

States
Life-cycles consist of states, individual state instances should be created under the relevant life-cycle categories.
States are later referenced from system instances, where a system can only have one state at a time in the current setup of the ontology.

Behaviours and Qualities
Behaviours and Qualities are instances of simple classes in the pertinent categories. In the current ontology each instance is represented with a name (slot) only.
The categories should be carefully chosen for both set of concepts, otherwise can be time consuming to re-factor an instance of a quality into a category in order to register finer grain qualities. Same challenge applies to registering behavior.

Topology and Systems
Systems, and sub-systems, are captured in some form of hierarchy in the ontology – the Topology. The Topology for systems is not pre-defined as it mostly depends on the method applied to systems analysis, and somewhat depends on the different types of systems as well.
Topology is withing the System ontology, it is captured together with the system instances, unlike the categories for life-cycle, behavior and quality.

System instances are created within the topology, where they automatically inherit characteristics of LivingThing and CategorizedThing.
The topology does not have a notation of structure for system elements, therefore predefined (in the SystemSpace) structures should be applied as Super-classes to specific topology classes. Note that sub-classes in the topology will inherit structures from parent classes, for that reason structures should be used sparingly in classes closer to the root and should be applied to classes closer to the instances.

Data characteristics of system elements are defined within of the Topology by adding them to specific classes. Data details are esentially attributes (slots here) on a class. One should be careful making sure that data is not confused with structure. Slots with references to other system instances are perfectly valid data elements, however these can be easily confused with structure elements also represented as slots. The success of proper separation will depend on the rigour applied to systems analysis.