Category Archives: digital transformation

  • -

Agile and Digital Planning

Category:digital transformation,EA,UK Blog

SAFE and scaled agile development is the new mindset for many product-oriented businesses as a smarter way to get pace into software development. Often the speed of delivery is increased as autonomy supports local decision power and more open-ended development and with dedication by a local product manager in each product team.

However, some decisions are more enterprise-wide and more strategic, so how to make the right balance between central planning and local authority? Known risks to SAFE are that in practice it does more single-loop learning than double-loop-learning, so it it often goes with the skills the team currently have. The team accepts their existing constraints, which automatically limits the potential for a high-growth offering. Second, the team curtail their ambitions on the product. Instead of a major breakthrough, they tend toward only incremental improvements on existing offerings. In other words, agile is not for every situation and it still requires strategic planning and digital planning at corporate level to support the overall strategy.

Digital Planning is the discipline to work with long-term strategic actions without being detailed of how to implement activities. It provides an overall investment focus to values and outcomes and how this ties into the investment streams to provide digital road-maps for planning. While the old approach of power-point based IT Road-map planning seems dead, the digital formulation exists and helps direction-setting the entire purpose of planning.

Planning may be situational, just like detailed plans always will depend on the specific case, situation and conditions. The difficult part of planning is the uncertainty of the future: One may shorten the horizon to improve the likelihood of estimate,  improve the underlying model, or reduce the feedback from the prediction to mitigate the uncertainty. However, does it in context of strategy and market remove the need for planning? The answer is “no”. The ubiquitous purpose of strategic planning is to become aware and be prepared – and that clearly involves more stakeholders and is very different from the actual plans or project performance. We came to the conclusion that there are five fundamentals as to why strategic planning is important – and despite their inherent uncertainty, they are more required than ever!

  1. The opposite of Planning is not no-planning; the opposite seems to be detailed plans or loads of backlogs that are excelled into beyond the point of validity. Planning serves a higher purpose.
  2. Projects differ in uncertainty – to what degree are they repetitive and common? Should we really apply the same methodology to all types of development?
  3. Situational transition dictates what methodology to apply  – How to secure the right toolbox for the right type of development?
  4. The definition of Planning is that well defined? If you ask the chef, planning is to have the groceries for the dinner same day, whereas for the farmer to produce the crop for harvesting season. Do we mean the same even though we use the same wording?
  5. Not to mention the data-connectivity – only an old-school architects would do product roadmaps in PowerPoint. If planning is democratized, poor planning is the same as a poor information based on no-connectivity and silo-approach.

Let’s go through these fundamentals one-by-one:

A: The opposite of Planning is not no-planning

The ubiquitous purpose of planning is to become aware and prepare. So planning has a value to understand, e.g. why a competitive product or service is challenging a revenue, and very different from executing a marketing plan without changing it – or changing the product or service, if indicators show the battle will not be won. Dwight D. Eisenhower once said,

“In preparing for battle, I always found that plans are useless but planning is indispensable”.
– Dwight D. Eisenhower

For a company to survive the coming 3 or 10 years,  it is hard to argue that no considerations of external threats, technology changes, emergent legislation should not be considered. But equally fair to guess, that even considered, the actual impact will not be fully understood until later in time. May well be that the forecast is poor and the prediction ends up being wrong or displaced, but planning as the preparation and improving the agility of what to respond as an enterprise is indispensable. The purpose of keeping the foundation of the planning intact is crucial in a digital world. Scenarios of what-if alternatives might be understood, and the opposite is not no-planning. The opposite is a constant pressure on doing the execution of the approved plans.

B: Projects differ in uncertainty

To what degree are they repetitive and common? Should we really apply the same methodology to all projects? Agile is certainly something we advocate for open-ended discussion, but if you happen to have more close-ended solutions, the construct of agile approach may be much too time-consuming. Agile goes well when everyone is uncertain – that will eventually lead to planning. However, if the project is to setup yet another new shop, the type of project may not be new, and the approach to seek experiments and agility may be less urgent.

C: Situational transition dictates what methodology to apply

The STARS approach by Michael D. Watkins ought to be mandatory reading for all information architects.

If you have something to protect such as knowledge, services, brands or patents, you will likely be in a sustain or realignment situation where you have time to act and provide planning of how to secure your assets as part of a business transformation.

Typically architects asked to help in a turn-around or start-up’s will have a much harder time, when speed of action weighs higher than thinking to protect parts of as-is. One could argue, that that the act of planning, in case of a change in oil prices is really to prepare for a worst case scenario, such as a 50% cut in price per barrel, before it happens. But as we don’t know the prices in the future, the specific plans are likely of no use – but if we can carve-out the actions to take given specific what-if conditions, that may be indispensable as the new way to do long-term planning.

D: The definition of Planning is that well defined?

Is the definition of Planning that well defined? If you ask a chef, planning is to have the groceries for the dinner that evening the same day, whereas the farmer needs to know what to grow before harvesting season. Do we mean the same even though we use different wording?

According to Wikipedia,

“Planning is the process of thinking about and organizing the activities required to achieve a desired goal. It involves the creation and maintenance of a plan, such as psychological aspects that require conceptual skills. As such, planning is a fundamental property of intelligent behavior.”

So even here planning has a wide range of meanings, and provided the desired goal is to continue as an enterprise, we should all maintain a plan of how to survive in the market. Maybe that is different from the actual 3-year road-map, however, if the plan mandates to migrate to a new payment platform or banking platform – how can we do this without more detailed planning?

E: Not to mention the data-connectivity

Only an old-school architect would collect excels for planning, so is poor planning the same as a poor architecture? Or could it be that poor planning is often the immediate outcome of poor information management? As described in other posts, we see the concept of living architecture or new architecture as a fundamental for successful planning. Because pace of change is increasing, and management calls for better ways to get insight to what-if. the objective of digital planning is collectively to prepare more for these events.

Which services should we expect to use the coming years? Where are the candidates for take-out? What new offerings will fuel our revenue? Such analysis should not be project deliverables, but be part of an ongoing planning where data may be connected and viewed in new ways to support few-clicks to better fact-based decision support. By revitalize the architectural information you can move the data governance to be automated and be part of the strategic agenda.

We tend to say that long-term planning needs to align with short-term planning, which is an ongoing process – and a digital process of information management. Long-live the digital planning – may be part of the digital transformation!

We simplify and amplify digital planning!

 


  • -

Digital Planning and TBM in the strategic race

Category:cost,digital transformation,EA

The idea of digital planning is to harvest the benefits of Enterprise Architecture to capture the holistic perspectives of an organisation between strategy and planning, and how to set priorities for aligned responses to daily delivery. To avoid siloes of behaviour, it is important to set the right focus on ideation and investments to win the battle of future revenue and future delivery.

Digital planning embraces:

  • Strategic planning and enterprise architecture
  • Capital and cost planning
  • Resource planning
  • Knowledge planning
  • Program/Project portfolio management
  • Risk Management
  • Security and privacy management

The approach of Digital Planning aligns with the principles of understanding how investments support standardised processes for ensuring alignment and strategy to execution. A key ingredient is to understand the difference between cost and value. While value relates to goals and outcomes, cost represents a spending, typically limited budgets, so how to create more by improving the efficiencies.

People using only architecture frameworks like TOGAF, ArchiMate, etc. may overlook the financial perspective and financial sponsors; likewise, people only focusing on TBM and cost profiles may approve spending case-by-case ending up with approvals that represent “siloes” of interest and do not align to the holistic and end-to-end perspectives of an organisation.

TBM has been seen as the new de-facto framework for comparing cost and IT Cost Management to support a standardised IT investment business case process and support comparisons year-on-year, month-by-month of IT Cost.

The early introduction of TBM was introduced by the US Federal Government’s Office of Management and Budget in 2005 and aligning well principles of large international corporations, hence it has a background in the public sector across the fifty states with annual updates to support federal agencies with budget planning, and IT cost guidance.  In 2016 -2017 an revision introduced a name change to TBM, which is short for Technology Business Model.

An advantage of the TBM is that it provides an intersection between the CIO and the CFO interests, helping organisations to understand where in the architecture that cost exist, and how increase efficiencies on the planned IT Cost.

The TBM provides a standard taxonomy to help in reporting with a traditional focus on IT Towers that aligns well with how most companies structure their IT cost and easily can relate IT Towers to organisational cost centres. At the same time, it does remove the organisational differences as IT Cost is now expressed in terms of the IT Towers that are standardised across industries and corporations.

The TBM view also supports the traditional CFO perspective into financial allocations, and finally, it aligns also to standardise service catalogue that even though different organisations have different services, they can be expressed in a common taxonomy with the TBM services.

Hence, every cost item can be expressed as a triplet, helping to build smart cost models and improve efficiencies. This is something that is supported by a TBM council, and is clearly a benefit for Enterprise Architecture as the value of the architectural break-down aligns perfectly with the TBM cost break-down.

With next-insight there is a unique opportunity to align architecture (ArchiMate, BPMN, etc. ) with planning, resource forecasts, governance, risk and compliance with IT cost management (TBM) in a single portal.

We can advise you and help your to automate your governance – making it digital. We advise, guide and implement relevant support systems to master your IT Management, from strategy to execution.


  • -

Set the “right” strategy team

Category:digital transformation,enterprise architecture,governance

Strategy is about setting targets for the future, choosing the right direction based on insight to market and resources. Strategy leads to strategy execution, but strategy execution is about delivery, minimising risk and getting the organisation to deliver the strategic ambitions – something that requires people, process and technology to be involved.

Malcolm Gladwell has written “tipping point”, how to make strategy implementations to scale, see short reference here. It pictures the value of how few people can make a significant impact, something that is deeply desirable within digital transformation and strategy execution.

The “tipping point” in context of strategy execution and digital transformation  is that magic moment when a strategy-to-execution-portal like our low-code platform  as an idea or social behaviour within an enterprise crosses a threshold and spreads like wildfire.

To succeed a strategy is not so much about the formulation  (although that has be sound as well), it is equally about getting to the tipping point where the stickiness and roll-out seems to spread like wildfire.

In the book Gladwell argues that fundamentally three key roles need to be present for any idea to transition into reality, and the same seems to be valid for strategy and architecture solutions, if not more roles. As we advocate to use a low-code platform for providing rapid responses, you also need the supporting team to encapsulate people, process and technology. But which team?

To win a strategy execution and pass the tipping point, you need to construct your digital team to accelerate the journey. We typically advise to look for at least the following four roles:

Practice Manager:
The practice manager is an IT Leader with knowledge of your organisation’s applications and processes and best-practices. The practice manager acts in many cases like the project manager or lead architect to communicate what is in and what is out of the next release, to keep a tight focus between next release and solving the best value steps first. Ideally this role relates closest to the connector-role listed by Gladwell.

Usability Coach:
The usability coach has focus on the detail within a release from an end-user perspective. When things go fast, testing of the front-end starts often ahead of the back-end. It is imperative that the changes and development done is provided with sufficient validation to ensure functionality and  a strong end-users experience. This improves quality of delivery and aligns with the pretotyping manifesto. The goal of pretotyping is to help you make sure that you are configuring the right stuff, before you complete it right.

Salesperson:
The salesperson is typically a senior profile on the border of the team. He fosters ideas for new development injecting stakeholder wishes into the future roadmap. With the low-code engine as the digital platform, see next-insight, he is aware he can produce new functionality faster and better than traditional tools, and in his/her daily dialog he communicates the roadmap and gets in return more value requests to the team.

The Maven:
The maker of low-code configuration to meet maximum re-usage and business outcomes. The maven is the cross-stack expert driving the development along-side the other roles. The alignment between practice manager and maven is critical to support what is easy and fast to accomplish as proactive responses to business challenges.

The coherency of the roles is key for a strong delivery of a low-code setup implementing strategy. Unlike tool-vendors who push conversions of data, conversion of processes proposing stiff tools to soft people – this team can put customer-centric solutions in place where the platform adapts to the use-case. A tool without a team is lost, team without a low-code digital platform is slow.

We advise a safe and fast implementation of your strategy with a low-code digital platform and joint digital team to accomplish the strategic objectives. The right thing to do now and in the future is to provide the stickiness and success of a team with a scalable platform like next-insight.

#Interactive  #Collaborative #Connected


  • -

Digital Design and Enterprise Architecture – what is it?

Category:digital transformation,enterprise architecture,governance

Enterprise Architecture and Digital Design Digital, what is it?

Likely you will find as many answers as you will find people to ask, unfortunately, that is so. Maybe because the discipline is relatively “young”, or maybe as suggested by Martin v.d. Berg because practitioners and researchers put different meaning into the term; but likely also because it is seen as “supporting” rather than a “line” activity so the term “decision support” associates with it. Clearly, there are more interpretations to what it is.

If you smell the words, “Enterprise” and “Architecture”, you will likely ask yourself, what is an “enterprise”? and what is an enterprise architecture then? The term somehow makes it more theoretic, at the risk of sinking like captain Carlsen on his SS Enterprise, which in fact was his enterprise, a ship. In most cases, we can replace the word “enterprise” with “your entire business” or “your organisation with customers and market”, even though we would argue an enterprise could be a business unit or simply the entire or a subset of the business. In any case, business overall with an end-to-end perspective. “Architecture” on the other hand is about structure, how things are connected, what they are composed of, how they are used, how they look and are perceived. We often talk about good or bad architecture based on our experience, durability and interaction. In any case, everyone has a saying of this.

James Lapalme previously has argued, that Enterprise Architecture (EA) could be seen as one of three schools, either the Enterprise integrating, Enterprise IT architecting or Enterprise ecological adaption, where this post takes the proposition to put emphasize on the strategy to execution, marked more blue than the others; see Fig.

Enterprise Architecture is often expressed along-side strategy. That is, you may be manager for strategy & enterprise architecture as a combined title. It does give a clue, that enterprise architecture is about strategic thinking, about decision support with a focus end-to-end.

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analysing the execution of change toward desired business vision and outcomes.

Gartner

With such a definition, EA is the authority to lead enterprise responses by working with external disruptive forces, disruptive? This clearly brings EA into the strategic space working with future solutions to achieve vision and outcomes, if need be also with breaking structures and processes or even acquiring new offerings.

At the core, EA is about the bridging between where we currently are, and the future to achieve desired business vision and outcomes. Then this is the tricky stuff, how to help an organisation to transition successfully into the future? This is what EA practitioners refer to as transition architectures, small pieces of planning to provide strategy-to-execution. Often EA practitioners then put actions into roadmaps, so roadmaps are key for making influence more actionable.

Darwin put it slightly different in a different context with “survival of the fittest”, EA is about your “enterprise” survival, what planning do we collectively need to do to be “fittest” and succeed in the market. It is less about doing it, but to inform and encourage management to stay on-course using an enterprise perspective. With reference to J. Ross, we often refer to this as “digital design” (as opposed to many small solutions with individual designs), some would refer to this as enterprise design.

EA is decision-support and enterprise design; based on information and data (not only data). The more we can digitalise the creation of information from data, the closer we get to the core of EA, what to do with it. While Operations focus on today’s services to customers, EA is planning with the perspective of what services do we need in the future, and how to transform the organisation to make that happen. Strategy is sometimes about pace (do more, move faster), sometimes about the unforeseen changes (new competitor, disruptive forces) where market changes force a set of decisions to be made quickly to succeed in the future.

How to make such decisions? That is what EA is all about with frequent updates, collaboration, and enterprise governance – we talk about it as iterative and integrated as it connects tools and integrates business end-to-end. For IT and CI items it integrates with CMDB, around financials it integrates with Finance, and so on. EA is often staffed with senior people as it is a broad role that connects stuff from front-end to back-end of the organisation. It is about long-term business change enabled by collaboration and planning to deal with pace and disruptive forces. Building organisations around EA provides help you to achieve corporate agility to adapt faster to new external forces.

To staff a team to succeed with EA, you need to have more skills represented, see related blog. Finally, working with architecture services, please be aware that there are more architectural practices, please see picture.

Architecture roles – what roles exist?

The following drawing is a simple representation of typical architecture roles, where the Enterprise Architect is the broadest role. Architecture is more than one discipline: To manage detail is different from the enterprise perspective.  The various architecture roles are related, yet very different in skillsets required and target delivery.

The Infrastructure Architect has an important role in keeping IT Operations in mint condition – often tightly coupled to the IT Service Management (ITSM).

The Software Architect has a different role which puts focus on the development of an application that solves stakeholder needs. Such work must be detailed meeting all requirements through properly design, development, documentation, and testing.

The Solution Architect is often linked to project architecture with a focus on how projects get scoped to delivery with a perspective to make a design that is valid post project closure.

The Business Architect has a slightly different skillset – more focused on market and business analysis. This is very often connected to business management, business processes and the strategy development of a business area or future revenue stream.

The Data Architect has a more detailed focus on data management and bringing fresh data between systems to support information and business insights.

The Enterprise Architect seems to do somehow a little of all of that with a perspective to look more end-to-end, secure alignment to the overall corporate strategy and direction, closing the gap between why and how. Focus is often on knowledge sharing, collaboration, planning and compliance to ensure best patterns are selected and re-used towards strategy fulfilment.

We are in the business of helping you to provide successful business change to execute your strategy – reach out if you need advice how to build you architecture office.

 


  • -

Digital Transformation – The Cultural shift is paramount

Category:digital transformation Tags : 

Last month we met with CIO’s and EA’s to discuss the most important elements of succeeding with Digital Transformation. The first thing we discussed was the definition of a ‘digital transformation’ – to discuss and facilitate the discussion of how to differentiate it from ‘digitalization’. In essence, the following focuses on the transformation, not to mix up the two terms.

As ‘digital transformation’ at the heart it is about data and enabling a new business model, it is also about establishing a new culture. If ‘digital’ loosely means data, and ‘transformation’ means changing shape; then ‘digital transformation’ is about transforming the shape of the business model to use data smarter, i.e. it is about moving the organisation to a new paradigm where existing processes are ‘split’ rather than fitted and optimized to become data-driven.

This also brings us to the main takeaway. We can enable a digital transformation faster with proper technology and roadmaps, but at the heart, it is about people and changing culture. To succeed with the transformation, time and space should be challenged, which will impact the culture in different ways  – and it will challenge managers in today’s business operations.

This brought us to the second observation, if people are not freed-up to work with the new shapes, they typically drown in day-to-day activities focusing more on lean and continuous improvement. This is why many organisations decide to move transforming development to new sites or do acquisitions, as it seems too hard to change the prevalent culture.  

It brings to the surface the dialog of Schein versus Porter – is it the culture or the strategy that drives the change – What drives what? The main takeaway seems to be that the culture shift is paramount to the change, if not, the transformation effort may dilute. If we want to change the culture, we need to consider how this should be ignited, proven, and collectively accepted. Hence, the organization may have to challenge itself to step outside the comfort zone and challenge the type of earnings and offerings. Research by Warren Ritchie indicates, that innovation does not take-off by the size of the company. On the contrary, most innovation comes from either smaller or very large corporations as they both manage the working culture with slack and innovation focus. But be aware, most large corporations may tell you they have an innovation culture, but they may mix-up the words of a culture of continuous improvement versus that of transforming the paradigm!

For example, this, e.g. Spotify and other music streaming services decided not to invent a larger CD; and likewise, Philips who introduced the CD did get royalties from the former music cassette – they both changed the way services could be delivered – challenging the media, space and time. Is it likely that the organisation and culture of Spotify are different from that of the labs building hardware devices in the ’90s? – absolutely.

In a nutshell, different shapes of the business model, offering different services by use of new technology, time and space is the driver of the digital transformation. This will not circumvent continuous improvement of the existing processes of today’s operations, but it is not the same approach and success factors, see post. To succeed with a larger change, the shift of culture is paramount, needs to be addressed, but proper technology and approach may accelerate the pace at which your organisation can succeed. 

We can help you to plan the change, and may with our digital transformation suite accelerate the pace.