A recent article on the New Zealand Institute of IT Professionals Techblog describes a different approach to software procurement that has been adopted by the Ministry of Business, Innovation and Employment (MBIE) and the NZ Police, for the development of an Emergency Response System. This approach is a variant of Qualifications-based Selection (QBS - https://en.wikipedia.org/wiki/Qualifications-Based_Selecti
A few of us around the globe have been struggling for a while to find a suitable professional headline or title that describes the kind of planning, advisory and ‘architecture’ work that we do. Until recently I might have referred to myself as an Enterprise Architect (EA), from Enterprise Architecture coined by John A Zachman back in 1984. This is still fine for those of us who have our roots in information systems design and are happy to be seen by the majority as something like ‘master information technologist’. However, for those of us who have moved on, applying what we have learnt over the years to broader business issues and solutions, the EA title is now a very loose fit (perhaps more like a throttlingly tight fit!).
As a long time conceptual data modeller, it has become quite obvious over the years, that the most valuable contribution of the 'data' modelling process to many successful information sytems projects on which I've worked, has little to do with computers or databases per se, rather it is mostly about a process of understanding a piece of the world of interest in terms of the 'things' that occupy that world and how those things (products, contracts, accounts, locations, events etc), both concrete and abstract, relate to one another. In other words the 'rules' that govern that piece of the world, in the particular 'context of interest'. Such models are not only relatively easily translated into a form that computers can use, but are generally useful for:
- Human visualisation and understanding of a subject, or a problem space.
- As a basis for common agreement on concepts that relate to a subject or problem area (i.e. all talking the same language).
- For exploring new ways of thinking about a problem area, precipitating innovation.
The diagram below represents some ideas on resolving the meaning of different architectures.
Enterprise Architecture is repositioned to be truly the architecture of the enterprise. Enterprise Architecture as currently typically practiced is renamed Enterprise IT Architecture. Business Architecture is effectively the ‘high-level’ architecture of the entire enterprise. A layer is shown that represents the bridge between the ‘high-level’ business architecture and specialised architectures, which essentially refine the detail. I’ve taken the liberty of assuming that specialist architectures other than IT would make sense, although this idea needs a lot more development.
Now I may have become super sensitised to increasing use of the term, but it seems to me that use of the word 'alignment', apart from being yet another vague business mantra, actually provides some insight into organisation culture.
The concept of value in business is critical and yet remarkably elusive. As a business architect I'm very interested in the concept of 'value', as people's perception of value dramatically influences business design and decision making.
I’d like to share with you some quotes, including some of my own comments, from a (July 2009) discussion amongst a group of business architects from different parts of the world, where the question was posed: ‘What is ‘value’ in business?'
Information Systems and Information Technology are often thought of as though they were synonymous, which is a misconception that can result in projects with ill conceived goals that fail to deliver the required business outcomes!
Information Systems is a large umbrella referring to systems designed to codify, gather, create, store, manipulate, and communicate information.
The potential for a company to achieve its strategy can be said to be enabled or limited by the sum of its capabilities. This idea has been strongly adopted by the business archiecture community, which pursues a 'scientific' approach to business design, and where it has become popular to map or model an organisation's capabilities with a view to finding gaps or opportunities for improvement.
An issue here is that capability models tend to look similar to process models, or at least their components, the capabilities could easily be mistaken for business processes. So the question is how do they differ? Or to phrase it another way, is there any architecturally significant difference between a business capability and a business process? (And indeed, does it matter?)
Rather than attempting to describe this by quoting different definitions of process vs capability I have attempted to analyse the different meanings by developing a concepts map.