5 Trends Spotted at Forrester’s Forum for Technology Management

by

PwC had the privilege to sponsor Forrester’s Forum for Technology Management Leaders this week in Orlando and our team had a great time and learned a great deal.  We distilled our conversations into 5 trends that we think are picking up steam based on what we heard. 1. We are Nearing the Digital Moment of Truth Nigel Fenwick, one of Forrester’s principal analysts serving CIOs, described findings from their research on the state of “digital” in […]

The Museum of Future Housing Tech

by

On June 24th I’ll be at House Party 2014 ’Curating’ a ‘Museum of Future Housing Technology’.

What is a museum of future housing technology?

Well, that is up to whoever visits the museum! The visitors will be creating the exhibits!

During the day visitors to the museum will have the opportunity to:

  1. Join a group of interesting people
  2. Share and discuss their problems and those of their customers
  3. Pick an interesting area or theme from the discussion
  4. Prototype a technology enabled solution to their problem. Each team will create a prototype of an idea using Post-it’s, paper, cardboard, plasticine, role play, video, storyboards and whatever else can be found lying around.
  5. The prototype will become an exhibit in the ‘Museum of Future Housing Tech’

Hopefully over the day we’ll build up an interesting and thought provoking collection of exhibits as together we explore how technology might help us solve problems for ourselves and our customers.

Sessions will run at set times throughout the day and will last approximately 30 minutes, so hopefully there be lots of opportunity to drop in and contribute to the museum and view the freshly created exhibits.

The end collection of exhibits will hopefully be

  • A representation of some key challenges that the housing sector faces
  • A manifestation of some interesting and innovative thinking about how technology might enable solutions to those challenges

Sound interesting? then if you haven’t already head over here to get your ticket.

Fancy helping out and/or contributing to the ‘Museum of Future Housing Technology’? then please get in touch here

Categories Uncategorized

Not Another Framework? Part 2

by

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

Not Another Framework? Part 2

by

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

One-liner for removing *ALL* ZFS snapshots

by

Desparately needed this one after tinkering with a ZFS rolling backup script:

sudo zfs list -H -o name -t snapshot | xargs -n1 zfs destroy

Note: This will remove ALL snapshots. Use at your own risk.

Categories Uncategorized

Your enterprise and social media?! We’ve got an IDEA!

by

Social media is indispensable from the organizational environment. Where people collaborate interaction exists and since society’s large-scale adoption of the internet, social media shaped online conversations about, with and within organizations. Social media is a fact of life; it is no longer the question whether an organization should use social media, but how they should use it. However, research by Gartner shows that most social media initiatives fail to achieve participation from the community or to achieve any meaningful purpose. So why do some organizations fail in using social media, while others – for instance KLM – are extremely successful in it? I think because many organizations do not understand the importance of adequately incorporating social media initiatives within their organizational structure. They do not know how to use social media in the context of their enterprise and become a ‘Social Enterprise’.

Designing the Social Enterprise

I strongly believe in a sort of ‘manufacturability’ of organizations. With manufacturability I mean designing the organization(al change) by the use of business models, enterprise architecture and process management. These are the fundamentals of delivering customer value in an effective and efficient way (although more than just these disciplines is required). I think that social media should be subject to these disciplines too. Maybe social media is not that ‘manufacturable’ as a business process or architecture, in the end it is part of a ‘social system’ about which we should carefully think why and how we participate in it. It is indeed the field in which most of our customers (internal or external to our organization) are active. That’s why social media offers us great opportunities and hazards for creating and delivering customer value.

IDEA for the Social Enterprise

In the consortium project ‘New Models for the Social Enterprise’ we designed ‘IDEA for the Social Enterprise’. IDEA is an abbreviation for the Interactive Design and Engineering Approach. It offers a method – with its roots in design thinking – to incorporate social media in your organization. By several diverging and converging phases we propose coherent instruments which help you to understand the value of social media in relation to your business model, the related business processes and the customers.

To conclude: whether you like it or not, social media is one of the trends we cannot deny from a perspective of organizational design. Social media has become an important channel for creating and delivering customer value. In order to use social media in delivering optimal customer value, I am convinced that organizations need a good IDEA about how to integrate social media in their enterprise!

If you have any questions or interest in IDEA or our research project ‘New models for the Social Enterprise’, feel free to contact me at b.beuger@bizzdesign.nl

Categories Uncategorized