Main content

An introduction to architecting the digital enterprise

Charlie Bess Profile picture for user cebess June 1, 2015
Summary:
We are on the cusp of a new phase of IT. New models of architecture are needed for the digital enterprise.

A few weeks ago, I mentioned in a diginomica post that we are on the cusp of a new phase of IT and the previous approach to strategic, technical thinking will not be up to the task of managing the move to what many are calling the digital enterprise. This new phase is not going to be driven by the data, infrastructure or process analysis in quite the same way, so new models are needed.

The illustration to the right is one that Gartner has been using recently:

Gartner new model

This model is a high-level view showing how enterprises going forward will be formed by the integration of the business ecosystem and its digital representation. My view is that the triangle in the middle is where the most interesting opportunities lie for Enterprise Architects – it’s the relationships, the experience they enable and their automation.

The social movement of the last decade was the result of using technology to strengthen the relationships between people. Machine-to-machine technologies laid the foundation for the Internet of Things and was built on the relationships between things. The business ecosystem, service-based relationships made up XaaS. The collaboration between these previously separate cooperative networks is ripe for a strategic perspective that many call the digital enterprise and in which diginomica is especially interested.

Business today is more dynamic with rapidly changing requirements and uncertainty. Enterprises are moving beyond a product/transaction focus, instead looking to the on-going relationships enabled by services and platforms, yet the expectations for results continue to increase.

The tools available are rapidly changing and the possibilities for results are expanding. The traditional approach to document and maintain enterprise architecture is too costly and static, often costing as much to maintain each year as it cost to develop in the first place, until it is finally abandoned.

New approaches are needed, with a focus on relationships, not just traditional IT concerns. Addressing the issues of IT process management, technology and governance are necessary, but not sufficient for success.

The current IT business approach of 'design, build and run' is becoming less relevant, since the timeframe for a stable run phase is constantly being reduced. Also, the fact that the organization’s needs are being addressed by aggregating services from numerous third parties means that third party management is a governance issue that needs to be a core competency. The emphasis needs to move away from just a stable delivery phase into a more dynamic, flexible and automated collaboration-based approach.

Architects need to be more than map makers that leave the exploration to others. They need to move to become drivers (or at least facilitators) of relationships and collaboration. Their efforts have to be more externally rather than internally focused, as the enterprise becomes more intelligent in how it consumes the resources available. At some point, a map and plan need to be defined but first, real honest communications and vision are needed.

This will require iterations and a slimmed down approach to visioning, planning, documenting and communicating the architecture. It cannot be an ivory tower approach since working with development and integration projects will be needed, to structure sprints defining and validating architectural issues in a similar fashion to how agile development projects define and validate functional and non-functional requirements. The concept of the customer and their relationship needs are not as simple as it once was and this has to be recognized.

An interesting paradox exists though: the architecture needs to be flexible and iterative but an incremental approach to strategy is likely to kill an organization since they will likely be outflanked by competitors who experiment and are prepared to 'fail first.' Resolving this paradox is part of understanding the cultural issues of the organization that will almost certainly be a core part of execution.

To tackle these issues, an active approach to both the supply of architectural capabilities and the demand from the business for consumption, needs to be defined. The current team of architects will need to change their expectations of their role. The business expectations will need to change as well. This cultural shift will need to take place incrementally with proof-points documented along the way.

Of course some will see this as the classic consultant's pitch and to some extent they would be right. But remember this is a world where failing as part of an integral learning path are critical. Managing what happens along the way is not just good practice but essential for those who understand that failure is simply an opportunity to learn i this context.

One suggestion though - don’t start with doubters. Generate momentum among the believers before you go after those. Make your initial efforts small but impactful, so those involved can be evangelists for the future. They will hold the keys to that old saw 'adoption' in cultures going through change.

Loading
A grey colored placeholder image