Technology moves faster than ecosystems
When Technology Moves Faster Than Ecosystems: An Architectural Framework for…
Architecture Principles
Hello Human Intelligence, meet Complexity Crunch
Just an announcement that the video of the ‘fundamentals’ part of my recent talks on essential insights on technology and psychology in relation to the digital revolution is now online on my YouTube channel.
Can we break through the inertia that plagues IT-change?
You’re on the Titanic. The engineers are shouting: “The bulkheads are too low! The rudder is too small! There aren’t enough life boats!”. The sailors mumble: “It has been cold, there will be many more icebergs than usual and further south”. The owners …
Will McKinsey be the first ‘big consultancy’ that gets (enterprise) architecture right?
McKinsey seems to be the first ‘big consultancy’ that really frees itself from outdated, ineffective, orthodox enterprise architecture notions.
Architecture principles considered harmful
Architecture principles are a very popular tool in the enterprise architect’s tool box. The underlying concept of ‘comply or explain’, however, makes them particularly toxic. [This article originally appeared on InfoWorld in 2015. It …
Presentation Chess and the Art of EA available on YouTube
I have given presentations of my story several times in the last years. From guest lectures at a university to conferences (3 hours) to presentations such as the Gartner Enterprise Architecture Summit (45 minutes). I’ve recorded an audio track with the … Continue reading →
Looking Back on Year 4
I write this post as part of a fond farewell to the University of Bristol as I have now concluded my very enjoyable 4 years as Enterprise Architect there and I have just moved on to the role of Senior Enterprise Architect at the University down the road – UWE! UWE are building quite a […]
Looking Back on Year 4
This post is part of a fond farewell to the University of Bristol as I have now finished a very enjoyable 4 years as Enterprise Architect there and I have just moved on to the role of Senior Enterprise Architect at the University down the road – UWE! UWE are building quite a significant EA […]
New Enterprise Architecture Column: On Slippery Ice
Principles and guidelines are not architecture, and if your main product is principles and guidelines, you’re not an architect. Continue reading →
Not Another Framework? Part 2
In my last post Oh No! We need another Practice Framework, I developed the earlier theme commenced in “Beware the New Silos”. I argued that the widely used frameworks are narrowly discipline centric and actually inhibit cross discipline working. I described how my own firm’s experiences have led to the development of a de facto framework, (we call it SOAM) and illustrated how this is essentially a value chain commencing with customer demand and finishing with value add to some enterprise.
I ended by sketching some basic principles concluding that we need a new framework that is goal driven and incorporates the entire value chain of capabilities, which of course may selectively reuse some parts of existing frameworks. In this post, I suggest a strawman that covers a) principles and b) capability model.
Before diving into principles, it will be useful to declare some scope. Our framework has developed from working with larger enterprises, both commercial and government in the area of business service and solution delivery. All of these enterprises share common issues that they have extensive legacy application assets that act as a serious inhibitor to business change, and successive, narrowly scoped solution projects over many years have often resulted in great complexity and technical debt. It is also common in my experience that enterprise architecture functions are routinely bypassed or ignored; that Agile methods have been attempted and found useful on narrow focused projects, but because of the constrained focus, tend to increase overall complexity of the ongoing application asset base; that consistent customer experiences are commonly compromised by narrow focused projects; and line of business managers in large enterprises are frequently dissatisfied with IT application service support.
The objectives of the framework are to:
– describe practices relevant to service and solution delivery in the digital business environment
– achieve a balance between short term goals and longer term objectives
– support progressive transformation to an enterprise comprised of independent business capabilities
– facilitate continuous, short cycle time evolution of business capability
– progressively and continuously resolve legacy portfolio complexities
– enable rapid delivery at low cost without compromise in quality
Principles are foundational for any framework.
Principles should be enduring and lead to both excellent policy communication and policy interpretation in everyday situations. I also find it useful to classify principles by subject.
Capability Model
In business architecture the capability model has become ubiquitous. And in thinking organizations I observe delivery of highly independent service and solution components that reduce dependencies and the impact of change, as well as mirroring the IT architecture on the business organization. Why wouldn’t we use the same approach in defining a set of activities to deliver services and solutions?
If you are uncertain about the capability concept, it’s important to appreciate that the optimum business capability is one that enables:
– maximum cohesion of internal functional capability, plus consistency of life cycle, strategic class (core, context, innovating . . . ), business partition (global, local, LoB . . ), standardization, customizability, stability, metrics and drivers
– defined, stable dependencies that are implemented as services
[Further reading on capability optimization ]
In the capability dependency model below, the arrows are dependencies. For example, Demand Shaping is dependent upon Conceptual Business Modeling and Portfolio Management. So this is not a flow diagram, rather all the capabilities should be regarded as iterative, I will come back and discuss how Lean principles operate in a framework like this, and as discussed above, highly independent.
Most of the capabilities in the model are self-explanatory. However some need explanation:
1. The Conceptual Business Modeling capability is the ability for business stakeholders to describe business improvement in conceptual terms. Many business people speak in solution terms. Most business requirements therefore surface as solutions, some more baked than others. Because the business stakeholder generally has the budget, the solution vision frequently drives and shapes the project with outcomes that frequently compromise the existing and planned portfolio. By educating business stakeholders to communicate in concepts, the opportunity is created to develop the business improvement idea without preconceptions of implementation or product, and to optimize architectural and portfolio integration.
2. Demand Management is reasonably well understood. Demand Shaping is best regarded as a complementary capability that takes raw customer demand and decomposes into components such as pre-existing or planned services/APIs, considers opportunities for modernization and provisioning, and reassembles as a set of projects or project components that optimize the progressive development of the portfolio. Demand Shaping is primarily an architectural task, but should be run by a cross functional team including architect, product management, business design and technical expert roles.
3. The Architecture Capability is shown as a decomposition of sub-capabilities, essentially one for each View, plus modernization. Whilst modernization is not classically an architecture view, there is commonly a specialist requirement for modernization architecture that will include identification of appropriate transformation and transitional architecture patterns. The primary objective of all of the architecture sub-capabilities is to define realizable structure to meet the demand and, as discussed above, to optimize opportunities for modernization and provisioning. While there is no explicit enterprise architecture View called out, each architecture capability should be executed separately and iteratively for reference, portfolio, program, project and module, thereby defining progressive layers of standard functionality that will be common to the defined scope, as well as situation specific business functionality.
I will detail all the capabilities in a subsequent post.
Final remarks.
This high level view of the framework has attempted to list a set of principles and associated capabilities required to support the value chain illustrated in Part 1 of this extended blog post. What will hopefully have become clear is the need for architecture capabilities particularly to be involved throughout the value chain. This approach integrates all types of architecture (enterprise, service, solution, deployment . . . ) into the business improvement value chain and creates better opportunity to demonstrate the ROI on architecture. Further the approach prevents enterprise architecture particularly becoming divorced from mainstream business improvement and encourages a better balance of short term and strategic goals. What will not yet be fully clarified is how the framework is very strongly focused on realizing architecture in delivered services and solutions, as a series of successive collaborations. I will describe how this is done using a Lean approach in a subsequent post.
Not Another Framework? Part 2
In my last post Oh No! We need another Practice Framework, I developed the earlier theme commenced in “Beware the New Silos”. I argued that the widely used frameworks are narrowly discipline centric and actually inhibit cross discipline working. I described how my own firm’s experiences have led to the development of a de facto framework, (we call it SOAM) and illustrated how this is essentially a value chain commencing with customer demand and finishing with value add to some enterprise.
I ended by sketching some basic principles concluding that we need a new framework that is goal driven and incorporates the entire value chain of capabilities, which of course may selectively reuse some parts of existing frameworks. In this post, I suggest a strawman that covers a) principles and b) capability model.
Before diving into principles, it will be useful to declare some scope. Our framework has developed from working with larger enterprises, both commercial and government in the area of business service and solution delivery. All of these enterprises share common issues that they have extensive legacy application assets that act as a serious inhibitor to business change, and successive, narrowly scoped solution projects over many years have often resulted in great complexity and technical debt. It is also common in my experience that enterprise architecture functions are routinely bypassed or ignored; that Agile methods have been attempted and found useful on narrow focused projects, but because of the constrained focus, tend to increase overall complexity of the ongoing application asset base; that consistent customer experiences are commonly compromised by narrow focused projects; and line of business managers in large enterprises are frequently dissatisfied with IT application service support.
The objectives of the framework are to:
– describe practices relevant to service and solution delivery in the digital business environment
– achieve a balance between short term goals and longer term objectives
– support progressive transformation to an enterprise comprised of independent business capabilities
– facilitate continuous, short cycle time evolution of business capability
– progressively and continuously resolve legacy portfolio complexities
– enable rapid delivery at low cost without compromise in quality
Principles are foundational for any framework.
Principles should be enduring and lead to both excellent policy communication and policy interpretation in everyday situations. I also find it useful to classify principles by subject.
Capability Model
In business architecture the capability model has become ubiquitous. And in thinking organizations I observe delivery of highly independent service and solution components that reduce dependencies and the impact of change, as well as mirroring the IT architecture on the business organization. Why wouldn’t we use the same approach in defining a set of activities to deliver services and solutions?
If you are uncertain about the capability concept, it’s important to appreciate that the optimum business capability is one that enables:
– maximum cohesion of internal functional capability, plus consistency of life cycle, strategic class (core, context, innovating . . . ), business partition (global, local, LoB . . ), standardization, customizability, stability, metrics and drivers
– defined, stable dependencies that are implemented as services
[Further reading on capability optimization ]
In the capability dependency model below, the arrows are dependencies. For example, Demand Shaping is dependent upon Conceptual Business Modeling and Portfolio Management. So this is not a flow diagram, rather all the capabilities should be regarded as iterative, I will come back and discuss how Lean principles operate in a framework like this, and as discussed above, highly independent.
Most of the capabilities in the model are self-explanatory. However some need explanation:
1. The Conceptual Business Modeling capability is the ability for business stakeholders to describe business improvement in conceptual terms. Many business people speak in solution terms. Most business requirements therefore surface as solutions, some more baked than others. Because the business stakeholder generally has the budget, the solution vision frequently drives and shapes the project with outcomes that frequently compromise the existing and planned portfolio. By educating business stakeholders to communicate in concepts, the opportunity is created to develop the business improvement idea without preconceptions of implementation or product, and to optimize architectural and portfolio integration.
2. Demand Management is reasonably well understood. Demand Shaping is best regarded as a complementary capability that takes raw customer demand and decomposes into components such as pre-existing or planned services/APIs, considers opportunities for modernization and provisioning, and reassembles as a set of projects or project components that optimize the progressive development of the portfolio. Demand Shaping is primarily an architectural task, but should be run by a cross functional team including architect, product management, business design and technical expert roles.
3. The Architecture Capability is shown as a decomposition of sub-capabilities, essentially one for each View, plus modernization. Whilst modernization is not classically an architecture view, there is commonly a specialist requirement for modernization architecture that will include identification of appropriate transformation and transitional architecture patterns. The primary objective of all of the architecture sub-capabilities is to define realizable structure to meet the demand and, as discussed above, to optimize opportunities for modernization and provisioning. While there is no explicit enterprise architecture View called out, each architecture capability should be executed separately and iteratively for reference, portfolio, program, project and module, thereby defining progressive layers of standard functionality that will be common to the defined scope, as well as situation specific business functionality.
I will detail all the capabilities in a subsequent post.
Final remarks.
This high level view of the framework has attempted to list a set of principles and associated capabilities required to support the value chain illustrated in Part 1 of this extended blog post. What will hopefully have become clear is the need for architecture capabilities particularly to be involved throughout the value chain. This approach integrates all types of architecture (enterprise, service, solution, deployment . . . ) into the business improvement value chain and creates better opportunity to demonstrate the ROI on architecture. Further the approach prevents enterprise architecture particularly becoming divorced from mainstream business improvement and encourages a better balance of short term and strategic goals. What will not yet be fully clarified is how the framework is very strongly focused on realizing architecture in delivered services and solutions, as a series of successive collaborations. I will describe how this is done using a Lean approach in a subsequent post.
James Martin – A personal reflection
James Martin, technologist, methodologist, entrepreneur and philanthropist died Monday 24 June 2013 aged 79.
I first came across James Martin in the early 1970s. I went to a lecture he gave in London, and he captivated an audience of about 100 people for 2 hours on the topic of real time systems design. Later on I attended his famous seminars in London and Johannesburg. It was extraordinary how he held huge audiences for multi day sessions, with minimal audience interaction as he drove through the thousands of slides, delivered on two overhead projectors. In those days he was the consummate technology seer and he filled a need in the days before industry analysts.
Yet he was so much more than just a showman. I bought his book on real time system design in 1971 and this was my bible. And down the years I relied on his books in data modeling, database design and information engineering; they were detailed and useful to a practitioner.
I joined James Martin Associates (JMA) in 1986. I think I was employee number 30 and I had the privilege of working in what must have been one of the most extraordinary and innovative companies at that time. Even when I meet ex JMA colleagues today, we always recall how it was such a great place to be, where everyone was on the leading edge and contributing to the overall development of information engineering. We were taking his ideas and turning them into practical method and tools for many of the world’s largest companies and government agencies.
We didn’t see that much of James Martin. He would attend our annual JAM (sic) session, and if he was in town he might drop in, but that was rare. But he did get feedback. I was deeply involved at one stage, together with Richard Veryard and Mike Mills in developing ideas for Rapid Application Development (RAD) that we took to customer projects and of course appeared later in the James Martin book.
The core of his thinking was the idea that model driven systems were the future and at JMA and subsequently Texas Instruments Software (TI) we proved this by delivering the IEF based on James’ ideas, that became the leading mainframe and client server development tool in the early 1990s. Of course we knew even then that this tool was limited to a very narrow set of patterns, and history has taught us that there is a need for a much broader range of patterns, and varying levels of abstraction and intervention. And even as early as the mid-1990s we were working on componentization and service interfaces because we understood the monolithic architecture, however commercially successful for a short few years, was in reality a simplistic first attempt. Today the term CASE tool is widely disparaged. Yet I believe that James’ original vision will be realized, although the method of realization will be radically different, and by strange coincidence I blogged on this topic very recently.
James Martin provided inspiration for technologists by identifying big ideas, but he went further by detailing the ideas in his books and teaching and “having the courage of his convictions” by investing in start-up businesses. Which of course made him very wealthy. I would be proud to say that in my work and in everything that CBDI has developed, we have been true to some of the core principles that we hammered out nearly thirty years ago including model driven (including meta model based) and structured with maximum automation. And these are equally applicable to today’s Agile, fast moving world. Of course we (Everware-CBDI) have added and evangelized the principles of component and service oriented, but the original vision is intact.
James Martin was an idealist. In several of his works he developed his thinking for a utopian society where technology and automation are used for the greater good in education, health and creating a better world. Sadly I myself came to see some of his works as out of touch with reality. He failed to see the shoddy reality of how politics and politicians are incapable of leveraging technology to deliver better models for society, how the giant Internet companies are creating worldwide networks based on old fashioned capitalistic principles while espousing such things as “do no evil” and practicing tax avoidance, and governments are increasingly using technology to track the every move of citizens without understanding how to govern the use of that data.
I believe we will remember James Martin, but not necessarily for his big ideas like the early prediction of the Internet or his philanthropy. Rather we will come in time to reflect on his guidance that technology should be leveraged to improve society. Every time we destroy tens of thousands of jobs by introducing new technologies, we should be using the power of technology in education and resource mobilization to ensure that vast numbers of our young people do not remain out of work, or that older people can continue to contribute to society beyond conventional retirement age.