DXCTechTalk

as @psd said "Agile: make it up as you go along. Waterfall: make it up before you start, live with the consequences." https://twitter.com/... - that has important consequences for managing risk

I also wrote something on this a couple of weeks ago 'Marginal cost of Making Mistakes' http://blog.thestate...

@cpswan I can accept that as a good 140 char fitting description

@cpswan Fits well with why I say procurement needs to get on the digital transformation bandwagon - https://blogs.dxc.te...

bridge the gap between planning and action. Make learning part of your action, aka development. that is agile

one of the most important lessons (normally takes a couple of years) to learn is that Agile techniques have a context. They are not appropriate everywhere.

Waterfall - all you planning is upfront, as you move through the process flexibility diminishes. In Agile you start we less up front planning, and iterate your way through development, making adjustments and delivering working software.

I think that Agile is cultural - in that the culture must accept #GoodEnough and #LearnFromFailure... then what @cpswan said

@swardley - and Agile and Waterfall are not the only methods around. Concurrent engineering or incremental development may be more appropriate to a given context.

Agree, it is a cultural shift away from get it right the first time, to minimum viable product that is enhanced through fast iterations

@NewInstEcon : oh agreed. Long ago I did some work on marginal cost of change, last post on this was circa 2013 - http://blog.gardevia... .. and yes, many methods are needed.

@swardley Indeed - having rich choice of alternative methods gives more options to optimise cost benefit outcome.

We have been sharing books with clients including the DevOps handbook, The Phoenix Project, and The Innovators dilemma and driving the conversation to "fail early, fail often"...also, letting clients listen in on Scrum calls can excite them on their side.

define APIs.. that would be the best start

Show inefficiencies (with Value Stream mapping for example), be shocked, get started.

@ojacques2 couldn't be more right... what is the value of servicing an order in minutes vs. weeks to revenue/revrec?

Start with a Use Case that has visible business impacts; establish your foundry for Design, DEV, TEST and ensure a business sponsor engages to discuss outcomes that lead to next step momentum

there are several approached to this. I would look to our Quick Start and Diagnostic capabilities across the entire portfolio and align with client stated business needs. We can help you with that

containerize or dockerize.. its one way

We absolutely can compose whole applications via #models and #metamodels. Exhibit A: The DXC OmniChannel Platform https://github.dxc.c...

model driven not model defined. where's the automation? where's the dynamic solutioning?

Absolutely. For the models in business domain: https://www.amazon.c...

Model driven still needs a model definition approach

Well, I like Inventor's Paradox - a solution to a general problem if often simpler than a solution to a specific problem. Then the answer would be - generalize (discover a pattern), solve, and configure (to satisfy the requirement).

Some companies believe they need to establish a newco to compete with digital natives; others understand a digital platform is a viable starting point as a delivery on innovation. Early use cases must aim at best anti-competition points.

great question. we are in it now and leveraging insight from partners like DXC is critical. It takes real self examination of their key business drivers and where digital technologies can enable or enhance business performance.

what about getting the right info to the right robot?

Any pointers/ i around automation injection n DevOps implementation and adaptation around it

#1 starting point: Decompose monolithic applications into loosely coupled µServices callable exclusively via REST APIs

Another thought: leave the legacy untouched and start building new stuff next to it

Start with simple applications, breaking it down to independent deployable API (with its own lifecycle), adopting eventual consistency, event driven, etc. This will also help you to have a continuous delivery approach.

Another one: enable a parallel "modern" world, start all greenfield projects/apps that way and transform legacy incrementally to that operating model. There are a lot of benefits to transform legacy too and avoid the museum effect.

define APIs for the existing apps

frankly depends on the client landscape and current portfolio. This requires a simple diagnostic and understanding of business requirements. we can then design an appropriate roadmap. there is no one size fits all

Remember DXC offers a suite of QuickStart offerings for Applications which enable clients to get started with low risk and at a low fixed cost, typically within the client's sign off limits.

n-tier web apps can easily fall into a monolithic architecture. Although not really new, emphasis on loose coupling of application tiers is what is currently on our minds. Remember #SemanticCoupling is TightCoupling

I guess the new digital platform is the Cloud. Is it ready for us to create an online booking system for airfare and accommodation in one controlled distributed transaction? probably not.