Saturday, February 23, 2008

The Importance of Meta-Projects

The feature video on International Association of Software Architects (IASA) site last week provided. I wish I could reference the speaker and the name of the video but alas last weeks feature video has been replaced by this weeks feature video.

The talk was reasonably pragmatic discussion of Architecture by a staff member of delta airlines. What inspired me to write this posting was that a slide that depicted "Business Enablements" things, like agility and collaboration. It also depicted lists for Business strategy and IT strategy. This is nothing new but it reminded me I need to lift my eyes from the day to day IT projects and see what my organisation is doing for software development as a whole.

This is timely because its time for my branch to put together a plan for next year. Typically this has been very project-focussed. Of course I also hope to put together a good graphic although I doubt whether I can do as well as the delta-airlines chart.

Each business and each IT department has its projects to achieve some outcome for the business. My focus is on application development projects. Often these projects are part of a bigger business project and commonly involve business process changes and infrastructure changes. Another category of projects do not achieve direct outcomes for the business but allow the business or the IT department to undertake these projects in a more effective manner. For business projects these 'meta-projects' is what was referred to as "business enablements" by the IASA speaker. I will not be using the term further as my spell checker says "enablements" is not a real word, and I tend to agree.

To put these in context see the following table

Goals/ObjectivesBusiness Goals. Mission, Vision and StrategyIT Strategy
Meta-ProjectsBusiness meta-projectsIT meta-projects
ProjectsBusiness projectsIT projects

There are strong relationships between each cell in the table and its neighbouring cells. The business goals drive the IT strategy and also the business meta-projects. Business meta-projects may drive business projects but also meta-projects may be driven by projects. Neither the meta-project or project is necessarily the driver. This is the same with IT meta-projects and IT projects. IT strategy should drive the IT meta-projects and IT projects.

The IT Meta-Projects that my IT department is engaged in are:
  • SOA
  • Enterprise Architecture
  • Mobility (Supporting mobile computing devices)
  • Business Intelligence (Data Warehouse and Reporting)
  • Legacy Transition
  • Spatial Systems (Geographic Information Systems)
  • Online Project (Customer-facing IT systems)
  • Identity Management (Authentication/Privileges/Access Control)
  • Service Management (ITIL, Request Management, Change Management)
  • Performance Management (Individual Performance)
  • Cost Efficiency/Consolidation (ongoing)
  • Business Alignment (ongoing)

Some of these meta-projects have explicit planning documents explaining the plan. Others are more just acknowledged as the agreed direction of the IT department. Cost efficiency and business alignment are not specific projects but an ongoing focus of attention as they would be in most IT departments.

Some of these IT meta-projects such as Online Project, Service Management, Performance Management and Costs Efficiency have analogous business meta-projects. Business Alignment parallels the business meta-project of customer alignment.

This list of IT meta-projects has not previously been written out. It is surprisingly long, especially given the much longer list of specific software development projects that are on our books. Ideally each of these meta-projects should be explicitly planned, prioritised and monitored.

Meta-projects provide a foundation to the work an IT department does. They could also be referred to as 'foundation projects' but they are not necessarily just internal projects as they may be programs of projects that directly affect the business user. The meta-projects help build the look and the feel of the IT department. They establish its competitive advantage and its identity. Accordingly, it is important to get these meta-projects right and to provide them with the attention they deserve over the more day to day concerns of getting software out the door.

Saturday, February 16, 2008

Architecture on Valentine's Day

I attended the Australian Computer Society (South Australian Branch) Architecture SIG this week. It happened that this was on Valentines Day. This drew a few comments about our dedication to the craft of IT Architecture, as we chose to spend the evening talking about architecture rather than with our chosen partners.

There were two presentations. Paul Turner introduced the International Association of Software Architects (IASA) to us. They have just set up chapter in Adelaide and will associate with our Architecture SIG.

IASA is an international professional society for Architects. It provides standards, training, certification and advocacy for Software Architects. Paul discussed some fundamental questions such as:
  • What is an architect?
  • What is software architecture?
  • How can yo prove you are a software architect?
Paul explained how IASA could help answer some of these questions. The main item of interest for me is that one can now be certified as an Architect. You pay for training over a number of months and then get grilled by a board which determines whether you have made the grade. This is an interesting development and will provide some legitimacy to the role and credentials of a software architect.

Adam Davies then gave a demonstration of Ruby on Rails. I had previously heard much about this technology but had not seen it in action. It was a very competent demonstration and it was amazing how much Adam was able to put together in the course the demonstration without resorting to the "here is some code I prepared earlier" fallback. Rails is able to set up sensible defaults to field names, column names and object names and create mappings between these without much overhead. It seemed to be ideal for standalone applications but certainly had some features that would make it valuable in any software development environment.