3 years, 1 month ago

Modernizing the modernization strategy

I was amused this week to be contacted by Researchgate, a syndication platform that have somehow republished my paper Enterprise resource planning: Componentizing the enterprise application packages that was originally published in April 2000 by the ACM. [ref 1] It was entertaining reading something I authored over 15 years ago, but quite refreshing that much of the thinking makes sense today. The gist of the paper was to discuss how some of the package vendors had responded to the impending Y2K event by componentizing and service enabling their packages, many of which at that time were exemplars of the worst monolithic application architecture (sic). At that time I observed that the componentization was a key factor in the huge growth of the EAI (enterprise application integration) market, and provided a genuine alternative to the conventional “buy or build” choice by enabling “buy, build or reuse”.

And this is really where my thinking has evolved considerably. Fifteen years ago we were very focused on transactional systems with a much lower requirement for flexibility. Today, and indeed for the past decade, I advise a radically different approach which is much more strongly business focused.

All too often the big question that bubbles to the surface is “should we buy or build?” And not surprisingly the buy option is often seen as an easier option because current systems are viewed as problematic and the organization has little or no competence in large scale systems development. In fact, for many organizations that have outsourced IT, development is not seen as a core business capability. So the question of buy or build becomes focused on whether a suitable package exists at an affordable price, where suitable means “supports our processes and information needs as we understand them today”.  And package vendors are well equipped to demonstrate how they have readymade and low risk capabilities that have high levels of configurability.

These days I advise a focus on just two important questions:

1. What are the systems requirements of our future business?
Many enterprises recognize their business models are changing rapidly and that there are numerous triggers, including technology, regulation, demographics, climate change, economics and more, that only indicate much more volatility. Most enterprises operate established sector specific models that have many conceptual elements that are shared with competitors, with clear areas of differentiation. Geoffrey Moore [ref 2] gave us excellent vocabulary to describe the Core and Context areas of our business, in which Core business capabilities should be highly differentiating and Context capabilities are managed to be equivalent to the competition, but no better. So the primary question to attempt to answer is, how might the balance between Core and Context shift over the coming years? If the shift is likely to be towards the Context, where competitive equality is a high probability outcome, then a buy solution “may” be appropriate if there is a package that really fits with the business model. This could well be true of highly regulated industries, semi-state organizations etc. However all the signs are that in the general commercial market there is likely to be a frenzy of innovation of core capabilities. That a high level of unpredictability inherent in some of the major triggers would indicate the most appropriate strategy will prioritize maximum flexibility  and response to change. And that leads on to the second important question.  
2. What are the cultural requirements of the future business? 
Everyone will recognize the extraordinary innovation culture demonstrated by organizations such as Amazon, Google and the vast numbers of start-ups leveraging technology opportunities. And this cultural paradigm shift is not restricted to so called Internet companies. Many large, conventional businesses recognize the existential threat and have responded, integrating bricks and mortar operations and processes with Internet portals, apps, IoT and B2B architectures. Crucially evolving their products and services in which information is an integral component. And most of these innovating companies are exploring Agile development practices demonstrating the extraordinary innovation, productivity and quality that can be achieved by a convergence of business and IT skills and expertise. Some of these organizations have reinvented their business models because they have been brave enough to change from command and control to delegated responsibility development models. They are demonstrating tomorrow’s enterprise is an information enterprise where conventional demarcation lines between IT and business need to be challenged and reengineered. Do packaged solutions have a place in such a high innovation culture? Of course – for the obviously Context areas of the business such as general ledger and receivables they make sense. But for Core business capabilities, a packaged solution must look like the dead hand of a commodity.
You may ask, “but back in April 2000 you expected a flourishing integration market, based on buy, build and reuse, why is that not applicable today?” And my answer is, “That actually happened in the noughties. But today we have a different challenge. Burdening creative people with huge integration and semantic transformation complexity is not a great way to reinvent the future business, as the past will be an anchor holding you back. Integration will be necessary and essential, but your core business architecture should be optimized as much as possible”
In a recent blog post I said, “modernization is not about achieving a new plateau of capability and functionality. Rather it is about enabling continuous, short cycle time response to change”. It’s about creating an Agile Enterprise.
CODA: Geoffrey Moore’s concept of Core relates to the centrality and mission critical nature of a capability. This should not be confused with the CBDI-SAE concept of Core Business Service, which is the service layer managing the state of the business. 
References:
1. Componentizing the enterprise application packages , David Sprott. ACM April 2000 
Researchgate  (public domain)
ACM (subscription or pay as you go)
2. Geoffrey Moore, Dealing With Darwin
3 years, 1 month ago

Modernizing the modernization strategy

I was amused this week to be contacted by Researchgate, a syndication platform that have somehow republished my paper Enterprise resource planning: Componentizing the enterprise application packages that was originally published in April 2000 by the ACM. [ref 1] It was entertaining reading something I authored over 15 years ago, but quite refreshing that much of the thinking makes sense today. The gist of the paper was to discuss how some of the package vendors had responded to the impending Y2K event by componentizing and service enabling their packages, many of which at that time were exemplars of the worst monolithic application architecture (sic). At that time I observed that the componentization was a key factor in the huge growth of the EAI (enterprise application integration) market, and provided a genuine alternative to the conventional “buy or build” choice by enabling “buy, build or reuse”.

And this is really where my thinking has evolved considerably. Fifteen years ago we were very focused on transactional systems with a much lower requirement for flexibility. Today, and indeed for the past decade, I advise a radically different approach which is much more strongly business focused.

All too often the big question that bubbles to the surface is “should we buy or build?” And not surprisingly the buy option is often seen as an easier option because current systems are viewed as problematic and the organization has little or no competence in large scale systems development. In fact, for many organizations that have outsourced IT, development is not seen as a core business capability. So the question of buy or build becomes focused on whether a suitable package exists at an affordable price, where suitable means “supports our processes and information needs as we understand them today”.  And package vendors are well equipped to demonstrate how they have readymade and low risk capabilities that have high levels of configurability.

These days I advise a focus on just two important questions:

1. What are the systems requirements of our future business?
Many enterprises recognize their business models are changing rapidly and that there are numerous triggers, including technology, regulation, demographics, climate change, economics and more, that only indicate much more volatility. Most enterprises operate established sector specific models that have many conceptual elements that are shared with competitors, with clear areas of differentiation. Geoffrey Moore [ref 2] gave us excellent vocabulary to describe the Core and Context areas of our business, in which Core business capabilities should be highly differentiating and Context capabilities are managed to be equivalent to the competition, but no better. So the primary question to attempt to answer is, how might the balance between Core and Context shift over the coming years? If the shift is likely to be towards the Context, where competitive equality is a high probability outcome, then a buy solution “may” be appropriate if there is a package that really fits with the business model. This could well be true of highly regulated industries, semi-state organizations etc. However all the signs are that in the general commercial market there is likely to be a frenzy of innovation of core capabilities. That a high level of unpredictability inherent in some of the major triggers would indicate the most appropriate strategy will prioritize maximum flexibility  and response to change. And that leads on to the second important question.  
2. What are the cultural requirements of the future business? 
Everyone will recognize the extraordinary innovation culture demonstrated by organizations such as Amazon, Google and the vast numbers of start-ups leveraging technology opportunities. And this cultural paradigm shift is not restricted to so called Internet companies. Many large, conventional businesses recognize the existential threat and have responded, integrating bricks and mortar operations and processes with Internet portals, apps, IoT and B2B architectures. Crucially evolving their products and services in which information is an integral component. And most of these innovating companies are exploring Agile development practices demonstrating the extraordinary innovation, productivity and quality that can be achieved by a convergence of business and IT skills and expertise. Some of these organizations have reinvented their business models because they have been brave enough to change from command and control to delegated responsibility development models. They are demonstrating tomorrow’s enterprise is an information enterprise where conventional demarcation lines between IT and business need to be challenged and reengineered. Do packaged solutions have a place in such a high innovation culture? Of course – for the obviously Context areas of the business such as general ledger and receivables they make sense. But for Core business capabilities, a packaged solution must look like the dead hand of a commodity.
You may ask, “but back in April 2000 you expected a flourishing integration market, based on buy, build and reuse, why is that not applicable today?” And my answer is, “That actually happened in the noughties. But today we have a different challenge. Burdening creative people with huge integration and semantic transformation complexity is not a great way to reinvent the future business, as the past will be an anchor holding you back. Integration will be necessary and essential, but your core business architecture should be optimized as much as possible”
In a recent blog post I said, “modernization is not about achieving a new plateau of capability and functionality. Rather it is about enabling continuous, short cycle time response to change”. It’s about creating an Agile Enterprise.
CODA: Geoffrey Moore’s concept of Core relates to the centrality and mission critical nature of a capability. This should not be confused with the CBDI-SAE concept of Core Business Service, which is the service layer managing the state of the business. 
References:
1. Componentizing the enterprise application packages , David Sprott. ACM April 2000 
Researchgate  (public domain)
ACM (subscription or pay as you go)
2. Geoffrey Moore, Dealing With Darwin
4 years, 7 months ago

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. 
                  Beware the New Silos
4 years, 7 months ago

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. 
                  Beware the New Silos
5 years, 5 months ago

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. 
5 years, 5 months ago

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. 
5 years, 6 months ago

Back to the Future with The Theory of Constraints

In so many situations today I find business people are much more savvy with IT than they used to be only 10 years ago. And while this is a fantastic advance, the result is they are MUCH more likely to dictate the solution right from the outset. I marvel at how very senior business executives are now so conversant with the specifics of application architecture, particular packages they wish to use and Cloud deployment architecture. But of course this level of direction frequently facilitates rapid action, but without full and thorough understanding of the business issues.

We know that business people should be focused on the inherent business architecture, surfacing the opportunities for common concepts and business services, business platforms, product lines and channels; identifying where standardization and differentiation is appropriate, and where partitions are relevant, all in context with the business and market  model. Get this level of architecture right and you have the chance of delivering an agile business. Get it wrong and you are in instant legacy territory!

With this interesting problem in mind I browsed my bookshelves and came across Eli Goldratt and the Theory of Constraints (ToC). There was an AH HA moment! I first came across Goldratt nearly 30 years ago; I went to one of his lectures in London and have read many of his books, but I haven’t used the ideas for a good while.

The starting point is to develop a Current Reality Tree, initially a list and then a dependency hierarchy of Undesirable Effects (UDEs) (see redacted example below). This is used to determine the root problem and then to develop a Future Reality Tree with Desired Effects (DEs). And the techniques naturally guide the user to focus on the HOW, and separate out the WHAT. In the process I insert an Ishikawa (Fishbone) diagram between the CRT and the FRT. It’s really useful in separating Domain based issues into (people, process, technology . . . ) clusters and also teasing out the root problem.

I would be interested to hear from others whether they are using ToC, or indeed if there are other techniques that do a similar job.

.  
5 years, 9 months ago

Shared Vocabulary for Business Innovation and Modernization

Do you remember when computers were hard to use? In fact it’s just nine years since a GM press release asserted that if they developed technology like Microsoft, we would all be driving cars that for no reason at all, would crash twice a day, shut down and refuse to restart. Since then Apple has showed Microsoft the way, and we all use smart phones, tablets and PCs that are genuinely easy to use and remarkably resilient.

Because of this great leap forward in personal device usability the smart phone user on the proverbial Clapham Omnibus might reasonably expect that enterprise systems should be similarly easy to use and resilient. Unless of course she was a customer of the Royal Bank of Scotland (RBS), in which case she will have painful memories of last year’s high profile failure caused by the core banking system crash which corrupted tens of millions of accounts.

Once upon a time banks in general were regarded as leaders in the use of information technology. Yet last year several high profile systems failures signalled that banking systems, far from being leading edge, are in rapid decline. Banks aren’t the only culprits. Along with the banks, insurance companies, retailers and others are starting to offer their customers smart phone apps, notwithstanding that behind the scenes their enterprise systems are frequently held together with sticky tape and sealing wax.

The reason many enterprise systems are in such a poor state is commonly because there are three parties involved in managing the enterprise systems that have widely divergent goals and objectives. The line-of-business manager typically views the systems as support to the business process and a cost to be managed. The IT Architect views the enterprise systems as a set of capabilities that must be progressively modernized to support business innovation. The IT Project Manager is focused on delivering projects to time and cost.

These views are of course diametrically opposed. And under cost and time pressure the Architect is frequently the lower ranking player. In consequence the immediate needs of the business overrule longer term objectives of modernization, reduced complexity, flexibility and even cost of ownership.

The real issue is that the three parties do not have a shared view of the business problem. The line-of-business manager’s business process view does not correlate at all to the delivery project. The Architect should be the evangelist for business innovation and modernization but he or she is too easily squeezed in the cost and time discussion. And the Project Manager typically does not share the detailed technical project view with the line of business manager, and argues for a solution specific architecture that reduces project risk. The result is the existing enterprise systems get more complex and slower to respond to change. And the IT industry has been doing exactly this for as long as anyone can remember!

It’s extraordinary, but with all our high tech knowledge and skills we don’t have a vocabulary to articulate the business problem in a way that allows effective communications between the participants. Many IT organizations have embraced services as a way to organize systems capabilities more effectively. These might be Web Services or APIs or referred to collectively as Service Oriented Architecture (SOA). But, even if these software services are architected to align with business perspective, they are always managed as a technical matter, defined and managed by the IT organization.

Yet line-of-business managers do understand services as a business concept; virtually every business product today has a service component to it. The global service provider industry has formed around this idea, and in the UK today service industries account for 77 per cent of the economy. So while IT and business share the common underlying concept, at the practical level there is no meeting of minds.

In order to create a better bridge between business and IT we need to work with both the “how” and the “what” the business is, and we can do this by complementing business processes with business services. Business services are a very natural way to talk about “what” the business does today and tomorrow, while business processes focus on the “how”. Because you don’t reinvent an industry by just analyzing business processes, you also need to evolve and innovate with improved and new business services.

A good example of a service oriented business is Amazon.com Inc. They are well known as a service provider because they have constructed the Amazon enterprise as a set ofbusiness services which are offered to various external parties – enabling suppliers to sell second hand books or electronic goods on the Amazon platform; or providing data storage and Cloud computing services to other enterprises. The Amazon business services combine the compute and the business service integrating the commercial contracts, business processes, people, physical assets as well as the service interfaces that enable computer to computer or computer to device communications.
 

Using a common business and IT concept permits sensible analysis of whether a service is just a unit of cost, or what the strategic value is now and in the future, and what it adds to the business value chain. Given so many line-of-business managers are thoroughly familiar with the very high technology in their smart phones and other devices, it really is time for IT to treat the business as a mature partner and for the line-of-business manager to take real responsibility for the business service as a whole product.

Increasingly we see a convergence of IT and business organizations. The business service concept is an essential piece of vocabulary to focus on a business innovation and get everyone singing off the same hymn sheet to potentially huge advantage of the business. Just look at the Amazon example!

———————–
We will be running a workshop that explores these ideas in London in April in conjunction with the IASA UK Summit. If you can’t make the London event, (for geographic of schedule reasons) talk to me about how we can accommodate.

5 years, 9 months ago

Framework for Service Oriented Ecosystem

I note interesting debates about the need for a next generation EA framework. However I am disappointed by the less than radical nature of debate that, at least I, have observed. I submit a good place to start is with the fundamental nature of business and how it is evolving and to consider what the enterprise of the future looks like. There are many indicators that we are entering a new phase of IT exploitation that will represent a real paradigm shift. Paul Krugman suggests IT is at last becoming significant, enabling a technology revolution to rival previous technology revolutions. Krugman cites driverless cars as an example of the technology moving into the physical world that has the potential to power growth. I will also instance a wave of disruptive technology delivering high bandwith always on connectivity for billions of workers and consumers, mobility, BYOD, social networks, big data and next generation analytics, robotics and Cloud. And the widespread adoption of Agile methods is also highly significant.

This stream of disruptive technologies is having a major impact on enterprises and the way they work. A Gartner report released this week predicts that by 2017, 25 per cent of enterprises will have enterprise app stores where workers can browse and download apps to their computers and mobile devices. I think that prediction will turn out to be conservative. It’s striking that many if not most enterprises are already being run as a continuous stream of initiatives, driven by business competitive pressures which in many cases are triggered by the disruptive technologies mentioned. And strategic innovation is typically being delivered in Agile projects which will increasingly combine business and IT expertise in defining the architecture and requirements.

But this is still a conventional view, doing what we do today, faster, better cheaper. What’s more importantly is to look at how the technology will enable profound change that spans existing enterprise boundaries. Consider Krugman’s Driverless Cars. This revolution is set to change the shape of personal transport in the relatively near term and will involve capabilities such as telematics, insurance, road tolling, mapping, navigation, vehicle recognition, which span car manufacturers, the financial industry, local or state government, emergency services and so on. This is a new ecosystem in the making which will require near real time, collaborative services spanning multiple business sectors.

Is this driverless cars ecosystem an isolated revolution? I don’t think so; consider smart shopping which is already taking off like a rocket with showrooming, or the extension of mobile devices to sector specific applications such as drug testing, health monitoring. I could go on. The future is going to look like many, many ecosystems, rapidly evolving usually not in the control of a single enterprise.

So returning to the question about a next generation EA framework, we might put a few stakes in the ground:
1. The pace of change is increasing so fast that conventional approaches (frameworks) for modelling will be left behind.
2. Ecosystem architecture should be primarily about identifying how an enterprise leverages an ecosystem by providing capabilities and their business services that collaborate and evolve along with the wider landscape.
3. The future is “business service” oriented. The application is dead. Business Service Implementation would be a better term.
4. The Capability and Service architecture will be a strategic business asset.
5. Capabilities as highly independent units of business function will be the way the business is organized.
6. The primary task of enterprise architects will be to develop the Capability and Service architectures as part of the business design.
7. Enterprise architects will probably be renamed Capability and Business Service Architects and report to the CMO.
8. The framework scope must span the entire Agile life cycle. Architecture is no longer a top down precursor to delivery, it must be an evolving set of deliverables and inherently implementable. The framework therefore needs to support concurrent development of business requirements, ecosystem, service and solution architecture, modernization, plus service and solution specification and delivery.

What’s needed is a new framework that recognizes the enterprise itself is a series of overlapping business ecosystems that are in turn part of a series of ecosystems that transcend the scope of the enterprise itself. A new framework should be focused on the capabilities and their inter-connections and manage the development of the business ecosystem(s) to the advantage of the enterprise.

While Capability is a widely used concept, notwithstanding some significant divergence of definition, the missing link is the realization of the Capability. In our work we use the Business Service concept – which delivers the capability in a context free manner. It’s extraordinary that our business vocabulary doesn’t include the formal Business Service concept in the same way that we are able to talk unequivocally about Business Process and know we will be understood.

The core model underlying the framework for future business needs to be service oriented, but it’s essential that the model is fully integrated with business concerns, and enables an implementable architecture in a way that current EA models manifestly do not. The new framework is also highly supporting of Agile methods in the entire life cycle being lightweight, twin track, narrow scope based on the Capability and Business Service, and contract based dependencies.
We will be running a workshop that explores these ideas in London in April in conjunction with the IASA UK Summit. If you can’t make the London event, (for geographic of schedule reasons) talk to me about how we can accommodate.

Paul Krugman: We Are On The Brink Of A Technology Revolution That WillTransform Our Economy