Link: http://it.toolbox.com/blogs/ea-matters/to-be-or-not-to-be-bimodal-70484?rss=1

IT is not really about investigating the emerging Digital technologies landscape, their adoption strategy and roadmapping.

Link: http://intellyx.com/2015/12/11/has-agile-outlived-its-usefulness/

In the fifteen years since seventeen software developers met at a Utah resort and hammered out the Manifesto for Agile Software Development, Agile methodologies for building software have become the predominant approach worldwide. Yet, while there is broad agreement that Agile improves the chances of successful software initiatives as compared to the deeply flawed waterfall approach, Agile still faces many challenges, even after so many years.

Fifteen years is a long time in IT, after all. Technology refreshes occur typically once every three years. Given the increasingly rapid pace of change – not only in the software world, but across today’s increasingly software-driven business environment – perhaps we should move on. Is it finally time to kill Agile?

Problems with Agile Continue to Pile Up

Even though the lightweight, iterative roots of Agile go back well into the 1950s, the 2001 creation of the Agile Manifesto (as it’s come to be called) has become a watershed moment for the approach, defining its four core values and a dozen principles for driving the creation of better software.

In and of itself, however, Agile has never been a methodology. Rather, methodologies like Scrum and Extreme Programming rose to the fore, espousing the principles of Agile. Today, Scrum in particular has achieved a remarkable level of adoption.

Nevertheless, the problems and limitations of Scrum and the broader Agile movement have proven surprisingly persistent, in spite of the throngs of very smart people who have worked in various capacities with Agile over the years.

The numerous complaints about Agile include its lack of focus on software architecture, its emphasis on one-off software projects as opposed to building reusable code, and the reinforcement of the notion that the software development team is a self-contained group, as opposed to participants in a broader collaborative effort.

Perhaps the greatest concern over Agile, however, is the ambiguity of Agile’s principles themselves. Agile calls for self-organizing teams, but there remains no clear understanding of how best to self-organize. Agile also calls for the stakeholder or customer to be an active part of the team – but stakeholders have always resisted this participation, and when they do join the Agile team, they struggle with their role.

Read the entire article at http://www.forbes.com/sites/jasonbloomberg/2015/12/11/has-agile-outlived-its-usefulness/.

Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, Chef Software and Photon are Intellyx customers. None of the other organizations mentioned in this article are Intellyx customers.

Link: http://intellyx.com/2015/12/19/do-we-need-industrial-strength-agile-computing/

By Joe McKendrick

Has Agile software development run its course? If it has, what’s at the next level?

Jason Bloomberg, an IT architectural advocate, suggests that it may be time to move beyond Agile, the philosophy and set of methodologies that encourages collaborative, rapid and iterative software development between IT and business teams. In a recent Forbes post, Jason suggests that Agile isn’t sufficient for the challenges of today’s rising digital organizations.

There have been organizational issues arising in Agile implementations (actually manifested as Scrum or Extreme Programming). “Agile calls for self-organizing teams, but there remains no clear understanding of how best to self-organize,” says Jason. He cites the walls Agile has run up against in practice within enterprises:

Difficulty in promoting business participation: There has long been a reluctance on the part of business stakeholders to get immersed in the process. Perhaps there’s a continuing perception that software development is outside the scope of day-to-day responsibilities, or isn’t a part of formal job descriptions. “Stakeholders have always resisted this participation, and when they do join the Agile team, they struggle with their role,” Jason says.

Lack of focus on software architecture: Agile engagements tend to occur as “one-off software projects as opposed to building reusable code,” he observes. While there has been plenty of talk in recent years about the “industrialization” of software, much of the work still tends to be artisan in nature.

Silos: Yes, Agile is supposed to open up the development process, but it may have had the opposite effect. Many Agile projects have tended to reinforce the notion “that the software development team is a self-contained group, as opposed to participants in a broader collaborative effort.”

Read the entire article at http://www.zdnet.com/article/agile-computing-in-search-of-the-next-level/

Link: http://intellyx.com/2015/12/21/5-issues-with-agile-and-whats-next/

By Yaniv Yehuda

In a recent article on Forbes, Jason Bloomberg makes the point that despite technology typically refreshing every three years or so, Agile is still the dominant method used to develop software. Bloomberg goes on to list some major issues with Agile that have come up over the years.

• Lack of focus on software architecture
• Emphasis on one-off software projects as opposed to building reusable code,
• Positioning the software development team as a self-contained group, as opposed to participants in a broader collaborative effort.
• Agile calls for self-organizing teams, but there remains no clear understanding of how best to self-organize.
• Agile calls for the stakeholder or customer to be an active part of the team – but stakeholders have always resisted this participation, and when they do join the Agile team, they struggle with their role.

Despite Agile’s shortcomings, there are few that would suggest moving back to waterfall. Instead many are turning to Lean, which according to Bloomberg, is an outgrowth of the Lean Manufacturing movement that Toyota championed in the 1950s. Applied to software development, Lean focuses on eliminating any activity that doesn’t add value right away, and emphasizes how the team operates as a whole.

Read the entire article at http://www.dbmaestro.com/2015/12/5-issues-with-agile-and-whats-next/

Link: http://intellyx.com/2015/12/30/jason-bloombergs-top-four-forbes-articles-for-2015/

Forbes asked me to pen a retrospective for my final article of the year. To this end, I reviewed the articles I had written in 2015, and fascinating pattern soon emerged. The top four articles by pageviews, while each having a different topic from the others, still reflect a consistent theme of disruption.

It’s no surprise, therefore, that for each of these articles, an update is in order. Here, then, is the latest news from the articles that you, the reader, were most interested in – often in the words of the article subjects themselves.

Number 4: Salesforce Acquisition: ‘End Of Beginning’ For Cloud, May 1, 2015.

The rumors of Salesforce’s imminent acquisition turned out to be unfounded – but I still called into question whether acquiring Salesforce would make sense as a way for an acquirer to leapfrog its way to the cloud.

In 2015, however, the cloud story was mostly a red herring for Salesforce. For it, the cloud is a done deal. The real disruption is the Salesforce ecosystem – a point I drove home in a subsequent article in September.

Read the entire article at http://www.forbes.com/sites/jasonbloomberg/2015/12/30/jason-bloombergs-top-four-forbes-articles-for-2015/.

Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, C C & C Solutions and Stantive are Intellyx customers. None of the other organizations mentioned are Intellyx customers. Image credit: Todd Sternisha.

Link: http://intellyx.com/2015/12/31/architecture-in-an-increasingly-dynamic-world/

By Arthur Cole

But probably the biggest change in enterprise architectures is not the designs themselves but the ways in which knowledge workers will interact with them. While Forbes’ Jason Bloomberg raised eyebrows last year with a post entitled “Is Enterprise Architecture Completely Broken?”, he clarified later by saying that traditional EA is on the way out and a more open, egalitarian style is emerging. Tools like self-service provisioning are making it easier for business users to define their own operating parameters, so the enterprise architect won’t need to concern himself with portfolio management and other functions within traditional frameworks like TOGAF. Rather, the EA will be tasked with facilitating this self-service through governance and policy management so as to give non-IT pros just enough room to be productive but not enough to get them, or the organization, into trouble.

Read the entire article at http://www.itbusinessedge.com/blogs/infrastructure/architecture-in-an-increasingly-dynamic-world.html.

Link: http://intellyx.com/2016/01/07/has-agile-outlived-its-usefulness-2/

By John Friscia

Agile Away

Here are the chief problems Bloomberg sees with agile and its most successful offspring, scrum:

The numerous complaints about Agile include its lack of focus on software architecture, its emphasis on one-off software projects as opposed to building reusable code, and the reinforcement of the notion that the software development team is a self-contained group, as opposed to participants in a broader collaborative effort.

Perhaps the greatest concern over Agile, however, is the ambiguity of Agile’s principles themselves. Agile calls for self-organizing teams, but there remains no clear understanding of how best to self-organize. Agile also calls for the stakeholder or customer to be an active part of the team – but stakeholders have always resisted this participation, and when they do join the Agile team, they struggle with their role.

As Bloomberg sees it, ambiguity leaks into continuous improvement initiatives as well, such that the shape and timeliness of “improvement” becomes unreliable. Another issue is understanding where the agile team stands in relation to, among other people, third-party providers who do not hold values in common with the team. However, if agile is to be replaced, figuring out what will replace it is a little fuzzy.

Read the entire article at http://aits.org/agile/2015/12/has-agile-outlived-its-usefulness/?utm_source=I%2FS&utm_medium=CAI+Twitter&utm_campaign=Photo

Link: http://intellyx.com/2016/01/09/que-es-la-estrategia-ti-bimodal-bimodal-it-y-como-podemos-implementarla/

Link: http://intellyx.com/2016/01/12/why-bimodal-it-will-fail-trimodal-will-prevail-in-3rd-platform-ecosystem/

Conflicts are Inevitable – that Typical “Us” versus “Them” Mindset

With bimodal IT, you create separate teams, which results in disconnecting the two modes and lowers the overall quality of communication. Different camps may also experience huge conflict for influence, resources, and power. Due to human participants, just like any other domain, confrontations about limited resources are more likely to surface. Jason Bloomberg, Intellyx President, is another strong critic of Bimodal IT and calls the model “balderdash”. He claims that the Bimodal approach has little for the modern world of IT, just a disguised way of functioning in the 3^rd
platform in a rather restricted manner.

What is Missing? The Middle Component (think of them as “Settlers”)

A perceptive technology expert might voice his concerns about the two-mode concept as being “insufficient”. However, the Bimodal IT approach is much more than this. Among IT organizations that now find themselves stuck with poorly constructed loads of data that mirrors junk, Bimodal IT has created “spaghetti junctions”—an unmanageable state where performance is compromised, confusion prevails and reliability disappears along with escalated costs.

Read the entire article at http://www.infinitconsulting.com/2016/01/why-bimodal-it-will-fail-trimodal-will-prevail-in-3rd-platform-ecosystem/

Link: http://blog.opengroup.org/2016/02/03/the-unix-based-cloud/

By Harry Foxwell, PhD, Principal Consultant, Oracle® Oracle® Solaris continues to evolve as the foundation for critical private cloud implementations.  As the premier UNIX®  system in the IT industry, certified against The Open Group exacting standards for enterprise-level operating systems, … Continue reading →

Link: http://davidsprottsblog.blogspot.com/2016/02/going-beyond-defined-agile-methods.html

I’ve been spending nearly half my time in Philadelphia over the past while, and I just happened to have a spare Saturday yesterday, so I hightailed it downtown. I had two objectives – to explore the Museum of Art and to attend a Brahms concert by the Philadelphia Symphony Orchestra. One of the featured exhibitions in the adjacent Perelman Building caught my eye. It’s named, Work on What You Love: Bruce Mau Rethinking Design. I wasn’t sure what to expect; I certainly hadn’t heard of Bruce Mau before, but I am always interested in design and design methods.

The gallery is essentially laid out to be controversial, to challenge one’s status quo thinking. In a video, Mau says, “practically everything that we do is being designed or redesigned; if you think about the way that we live now our life from womb to tomb is a design experience. If we want a great life experience you have to design it.” Mau goes on to say his work is focused on allowing people who aren’t designers to have access to the power of design, in their life, their work, in their business. Giving people the tools to design their future in a highly positive way.

Almost at the door of the gallery is a huge exhibit detailing his “incomplete manifesto for growth”. And the manifesto principles look like a superset of the Agile development manifesto, but writ large, with vastly greater ambition. First there are 43 principles. What! I say to myself, how can that many principles be useful? But of course once you start reading you are hooked. The Agile principles are embedded, but there’s much more. Let me give you a taster:

1. Allow events to change you. You have to  be willing to grow. Growth is different from something that happens to you. You produce it.

5. Go deep. The deeper you go the more likely you will discover something of value.

8. Drift. Allow yourself to wander aimlessly. Explore adjacencies. Lack judgment. Postpone criticism.

9. Begin anywhere. John Cage tells us that not knowing where to begin is a common form of paralysis. His advice: begin anywhere.

13. Slow down. Desynchronize from standard time frames and surprising opportunities may present themselves.

16. Collaborate. The space between people working together is filled with conflict, friction, strife, exhilaration, delight, and vast creative potential.

20. Be careful to take risks. Time is genetic. Today is the child of yesterday and the parent of tomorrow. The work you produce today will create your future.

22. Make your own tools. Hybridize your tools in order to build unique things. Even simple tools that are your own can yield entirely new avenues of exploration. Remember, tools amplify our capacities, so even a small tool can make a big difference.

29. Think with your mind. Forget technology. Creativity is not device–dependent.

31. Don’t borrow money. Once again, Frank Gehry’s advice. By maintaining financial control, we maintain creative control. It’s not exactly rocket science, but it’s surprising how hard it is to maintain this discipline, and how many have failed.

39. Coffee breaks, cab rides, green rooms. Real growth often happens outside of where we intend it to, in the interstitial spaces—what Dr. Seuss calls “the waiting place.”

41. Laugh. People visiting the studio often comment on how much we laugh. Since I’ve become aware of this, I use it as a barometer of how comfortably we are expressing ourselves.

These are just a sample. You get the idea. This is Agile for the real world. For those people that are stuck in the zone of religious adherence to Agile development methods this may be anathema. But it’s a wakeup call. Invent your own.

The complete list and much more . . .

Work on What You Love: Bruce Mau Rethinking Design
November 21, 2015 – April 3, 2016

AFTERWORD: I wonder to what extent these principles map to a variety of design disciplines? In fact surely all design disciplines are creative processes. Would this include musical composition? I see no reason why not.

Link: http://intellyx.com/2016/02/29/spread-the-devops-virus-in-your-organization-part-one/

When an organization finally figures out how to get DevOps to work properly, it’s unquestionably a beautiful thing. A team working together at full speed, delivering value to their organizations, while laughing in the face of roadblocks that threaten to impede their progress.

Getting to this point wasn’t easy. We had to learn numerous lessons, many from Agile and Lean and other practices, each of which offered part of the answer. And then the technology itself had to reach a level of maturity, both among the tools themselves as well as the infrastructure. Clearly, DevOps owes much to open source. Not to mention APIs. Cloud computing and virtualization. And software-defined, well, everything.

Even taking into consideration those few but remarkable DevOps success stories – stories that are more frequent every day – the work of DevOps is far from complete.

As enterprises today undergo digital transformation, they become software-driven organizations. But software-driven is somewhat of a misnomer, because software alone is only an enabler – just as software-based tools are not the core of DevOps, but merely DevOps enablers.

In reality, to become software-driven, companies must transform organizationally – and the key to such transformation is self-organization.

What we’re missing, however, is a self-organization playbook. That’s where DevOps can help. Getting DevOps to work means getting self-organization to work. The challenge then becomes spreading the approach beyond the software organization.

For this reason I called for the spread of the DevOps ‘virus’ in my last Cortex newsletter.

We’re not simply taking a page out of the DevOps playbook and applying it to ‘non-software’ teams – assuming it even makes sense to talk about such teams in today’s software-driven world.

The goal, in fact, is more subtle: to leverage DevOps principles as a fundamental mechanism to achieve the organizational change necessary for digital transformation success.

Beyond Two Pizzas

At the heart of the DevOps culture, of course, is self-organization. Self-organizing teams, after all, are an Agile principle that serves us well today, as is the Lean principle (also familiar from Extreme Programming) that everybody on the team is responsible for everything the team produces.

Put these two basic organizational principles together, and you have the basis for cooperation, empathy, and responsibility. People working together to achieve a common goal is the essence of cooperation. Self-organization and joint responsibility facilitate empathy, since you can’t dump problems on someone else.

Nothing particularly insightful or new so far. The challenge, however, comes when we want to expand all this organizational goodness beyond teams of about eight to ten people – the perennial two-pizza challenge. In other words, how do we scale DevOps culture?

The two-pizza challenge, of course, refers to the adage that you can feed an ideally sized team with two pizzas. Clearly, if a team grows much beyond that point, then the ‘everyone is responsible for everything’ principle breaks down quickly.

How, then, can we spread self-organization more broadly? The key is to understand the primary factor limiting our success with self-organization up to this point: we’ve been assembling self-organizing teams all along.

As long as someone (a manager, say) assigns people to a team, the team’s ability to self-organize has just taken a big hit. Sure, team members can decide how to divide up tasks, who sits with whom, and so on. But there’s only so much self-organizing a team can do when someone has put together the team and given them an assignment.

The first key to spreading the DevOps virus beyond the two-pizza level, therefore, is to allow people to choose their own teams, and to allow teams to choose their own goals.

Cross-Pollination among Self-Organizing Teams

For an organization to be comfortable with such self-organization, people must have an understanding of various needs across the organization so they can best decide which teams they should help with.

There also must be adequate communication and collaboration among people outside of existing teams, so that there can be an interplay between the people on teams looking for additional help and the people who have the time, inclination, and ability to provide that help. I like to call this interplay cross-pollination.

Cross-pollination consists of the following general principles:

• Anyone can identify a business goal they wish to pursue and seek to assemble a team to achieve that goal. That person, however, must be on the team – it’s strictly against the rules for someone to organize a team they don’t belong to. (Stay tuned for part two of this Cortex for more advice to management.)
• Some people may participate in more than one team at the same time, since each team doesn’t need all of their time. Everybody on a team won’t be a partial contributor as a rule, but chances are some people on each team will qualify.
• Some people serve a role on a team for only part of the lifetime of the team. They may find themselves moving from one team to another as those teams need them.
• Nobody is ‘off limits’ when a team needs help from someone outside the team. Even customers are fair game. If a team thinks they need the help of someone else, they can ask anybody they think might help, or might know someone who can help.

Clearly, suitable social networking tools are essential for empowering cross-pollination. It’s no wonder, therefore, that collaboration and communication tools and techniques are such an important part of digital initiatives today (stay tuned for more insight into this topic in a future Cortex – don’t forget to subscribe!)

Decision Making on Self-Organizing Teams

The basic principle of decision making is for teams to do it for themselves, rather than some manager or other external party doing it for them. Here are the basics:

• It’s up to the team to decide how they make decisions. Vote of the majority? Possibly. Unanimous consensus? Might be worth a try. Let a leader decide? Perhaps – but note that the team also decides whether they need a leader and if so, who it is. Nobody has a pre-defined leadership position; instead, leaders naturally arise as a part of self-organization.
• Teams must be willing and able to resolve personal conflicts internally. Any team has the ability to kick someone out – but such an occurrence should be treated as a positive cross-pollination opportunity because it frees someone up to help elsewhere, thus turning a potentially morale-killing event into a positive result.
• All teams have natural lifetimes. When a team coalesces, they should generally give themselves an expiration date (or tie their dissolution to a particular milestone or other event). They can always decide to change this date if necessary, but the default is for teams to expect to disband, thus freeing members to join other teams.
• All teams should mind the cadence. In some cases the duration and completion times of various teams’ efforts are independent of each other, but it’s also common for teams to need to coordinate release cycles. Does this recommendation mean that there’s a need for a ‘scrum of scrums’ type coordinating team? Perhaps, perhaps not, as such a team should also self-organize.

The Intellyx Take: Where’s the Automation?

For an article that purports to describe a DevOps virus, there was scant mention of the technology enablers of DevOps. DevOps wouldn’t be DevOps without automation-driven continuous integration and continuous delivery (CI/CD), after all, right?

In fact, without CI/CD, DevOps would never have gotten off the ground, because ops folks would still have their hands full with manual tasks. The reason people could break down the dev/QA/ops silos in the first place is because the tooling freed up everybody to drive QA and ops more as extensions of development than as separate silos.

In other words, technology played an essential role in the evolution of self-organizational principles, helping move them from theory to production-tested reality.

Now it’s time to take the next step. To achieve the full vision of digitally transformed organizations, the maturation of technology and organizational principles must proceed apace. Each one needs the other.

That’s why I call this trend the DevOps virus. This virus is contagious. And we need it to infect the entire organization.

Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: jeffreyw.

Link: http://intellyx.com/2016/03/18/weekly-top-10-continuous-improvement-collaboration-and-innovation/

By Avigail Ofer

This week’s top 10 reminds us that there is always room to be continually improving and adapting. For example, the CIO role is becoming more involved with the digital transformations of organizations. CIOs should be focusing their teams on collaboration to breed innovation and implementing a service-centered approach to design to keep business booming and customers satisfied. Our weekly round-up covers several other areas to be thinking about to keep your company on top of the game – like how to keep your software testing relevant and why employees need to be Agile now more than ever.

“Finally, the conclusion: part two of my Cortex newsletter, Spread the DevOps Virus in Your Organization. In part one, I called for expanding the hard-fought organizational lessons of DevOps to the rest of the enterprise. Allow people to choose their own teams, and to allow teams to choose their own goals, I exhorted – self-organization being the key to driving agility at the organizational level.”

Read the entire article at http://electric-cloud.com/blog/2016/03/weekly-top-10-continuous-improvement-innovation/

Link: http://davidsprottsblog.blogspot.com/2016/02/going-beyond-defined-agile-methods.html

I’ve been spending nearly half my time in Philadelphia over the past while, and I just happened to have a spare Saturday yesterday, so I hightailed it downtown. I had two objectives – to explore the Museum of Art and to attend a Brahms concert by the Philadelphia Symphony Orchestra. One of the featured exhibitions in the adjacent Perelman Building caught my eye. It’s named, Work on What You Love: Bruce Mau Rethinking Design. I wasn’t sure what to expect; I certainly hadn’t heard of Bruce Mau before, but I am always interested in design and design methods.

The gallery is essentially laid out to be controversial, to challenge one’s status quo thinking. In a video, Mau says, “practically everything that we do is being designed or redesigned; if you think about the way that we live now our life from womb to tomb is a design experience. If we want a great life experience you have to design it.” Mau goes on to say his work is focused on allowing people who aren’t designers to have access to the power of design, in their life, their work, in their business. Giving people the tools to design their future in a highly positive way.

Almost at the door of the gallery is a huge exhibit detailing his “incomplete manifesto for growth”. And the manifesto principles look like a superset of the Agile development manifesto, but writ large, with vastly greater ambition. First there are 43 principles. What! I say to myself, how can that many principles be useful? But of course once you start reading you are hooked. The Agile principles are embedded, but there’s much more. Let me give you a taster:

1. Allow events to change you. You have to  be willing to grow. Growth is different from something that happens to you. You produce it.

5. Go deep. The deeper you go the more likely you will discover something of value.

8. Drift. Allow yourself to wander aimlessly. Explore adjacencies. Lack judgment. Postpone criticism.

9. Begin anywhere. John Cage tells us that not knowing where to begin is a common form of paralysis. His advice: begin anywhere.

13. Slow down. Desynchronize from standard time frames and surprising opportunities may present themselves.

16. Collaborate. The space between people working together is filled with conflict, friction, strife, exhilaration, delight, and vast creative potential.

20. Be careful to take risks. Time is genetic. Today is the child of yesterday and the parent of tomorrow. The work you produce today will create your future.

22. Make your own tools. Hybridize your tools in order to build unique things. Even simple tools that are your own can yield entirely new avenues of exploration. Remember, tools amplify our capacities, so even a small tool can make a big difference.

29. Think with your mind. Forget technology. Creativity is not device–dependent.

31. Don’t borrow money. Once again, Frank Gehry’s advice. By maintaining financial control, we maintain creative control. It’s not exactly rocket science, but it’s surprising how hard it is to maintain this discipline, and how many have failed.

39. Coffee breaks, cab rides, green rooms. Real growth often happens outside of where we intend it to, in the interstitial spaces—what Dr. Seuss calls “the waiting place.”

41. Laugh. People visiting the studio often comment on how much we laugh. Since I’ve become aware of this, I use it as a barometer of how comfortably we are expressing ourselves.

These are just a sample. You get the idea. This is Agile for the real world. For those people that are stuck in the zone of religious adherence to Agile development methods this may be anathema. But it’s a wakeup call. Invent your own.

The complete list and much more . . .

Work on What You Love: Bruce Mau Rethinking Design
November 21, 2015 – April 3, 2016

AFTERWORD: I wonder to what extent these principles map to a variety of design disciplines? In fact surely all design disciplines are creative processes. Would this include musical composition? I see no reason why not.

Link: http://intellyx.com/2016/04/11/the-three-threads-of-digital-architecture/

In last week’s Cortex newsletter, I introduced the following diagram of a customer-centric digital architecture, where digital architecture is shorthand for enterprise architecture that’s laser focused on driving digital transformation.

Customer-Centric Digital Architecture

In the diagram above, the traditional architectural layers (represented here as concentric bands) have been grayed out in favor of customer journeys that cut across user interface, process, technology infrastructure, and data concerns, instead focusing on the preferences and behavior of individual customers as they conduct all their interactions with the company in question.

The notion of customer journeys, of course, are central to the digital marketer’s playbook. Clearly, enterprises should focus their digital efforts on such journeys, as they represent customer interactions over time. But making customer journeys the centerpiece of the enterprise architecture, however, leaves more questions than answers.

The challenge arises when EAs consider the context of the customer journey in the overall architecture as well as the architectural elements that make up each customer journey. After all, dividing up the world into familiar layers like process, data, and technology is relatively straightforward. There are overlaps and ambiguities at the edges to be sure, but everyone approaches such layers with a relatively common understanding of the overall scope of each layer and what belongs within each one.

Approaching the enterprise architecture as a customer-centric digital architecture, however, requires more than drawing new boxes and sorting things into them. Rather, such architecture must take a different approach than EA has been done before, or the end result won’t meet the business need – which in this case, centers on addressing always-changing customer preferences and behavior. Customers are simply too fickle in their desires to expect traditional architecture to rise to the challenge.

The Three Threads of Digital Architecture

In order to flesh out this new approach, we need to pull together three threads in the tangled weave we call digital transformation: traditional EA, Agile, and scaled self-organization.

From traditional EA we take a reductionist approach to solving problems: breaking them up into well-defined chunks that have well-defined relationships with each other. This ‘boxes and lines’ notion of architecture is familiar to every architect, of course, and hearkens back to the Zachman Framework, TOGAF, and just about any other EA framework you care to mention.

Reductionist approaches, however, only take us so far, because they assume a level of understanding and stability that the real world rarely if ever offers.

If only we had a clear, stable understanding of our requirements that everybody agreed on, and only if our ‘final state’ was similarly clearly defined, then our architecture would be straightforward.

We all realize by now, however, that such ‘waterfall’ thinking almost always leads us astray, because rarely if ever do the assumptions listed above hold true. Instead, we should always assume that we don’t understand the requirements, that there’s no such thing as a ‘final state,’ and furthermore, we must also take for granted that everything is always in a state of flux.

Fortunately, we have an established set of principles for dealing with situations of unclear, continually shifting requirements – the principles we loosely group under the Agile banner: iterative, customer-focused approaches that focus on solving the problem at hand instead of other, less important tasks.

So far so good, but while combining Agile principles with EA – what people predictably call ‘Agile EA’ – is an important step in the right direction, it doesn’t take us far enough to solve the challenges we have with Digital Architecture.

The problem: Agile principles focus primarily at the local, team level. And while there are several approaches to scaling Agile, like the Scaled Agile Framework (SAFe), for example, they all suffer the same fate: as they rise from the team level to the enterprise level, they lose the inherent agility that is necessary to satisfy the preferences and behavior of customers that form the basis of digital architecture.

Solving this problem requires us to pull on the third thread of digital architecture: self-organization. Not merely the team-level self-organization that has been a part of Agile since day one, but rather self-organization scaled across the enterprise.

The Missing Piece of the Digital Architecture Puzzle

Circling back to our original questions about customer journeys at the architectural level – the context of each journey in the architecture as well as the relationships among journeys – the answer lies in scaled self-organization, within the context of Agile EA.

Let’s take an example. Say you’re an executive at a large consumer bank, and you realize your interactions with customers are sorely lacking. It would be easy to say you need a better mobile banking app – and perhaps you do – but focusing on a single app rather than the entire customer journey won’t solve the larger problem.

In reality, the customer journey involves not just the mobile app and your web site, but also your call center, your outbound marketing, your branches, and of course, all the back end systems that make everything work. And then you also realize that even this list is likely to be dangerously incomplete.

So, who do you turn to in order to put together all the people and other resources across numerous departments to get the customer journey right? And how do you place this particular customer journey initiative into the context of all the other digital initiatives that are clamoring for attention and resources?

The answer is to call upon the people who know best what your bank does, and furthermore, what it can do – your own employees. Follow the basics of self-organization (see my previous Cortex newsletters, Conway’s Law and the Emergence of Business Agility and Fixing Slow the Agile Digital Transformation Way for more details), and then get out of their way. (Subscribe to the Cortex newsletter here.)

The Intellyx Take

What, then, is the role of the EAs in this vision of scalable self-organization? First and foremost, they are on the self-organizing teams themselves, including both the teams that form around specific business challenges as well as the Center for Digital Empowerment that helps to coordinate and empower all the digital efforts across the enterprise.

As for the enterprise architecture itself, its focus is on facilitating the transition to scalable self-organization, within the context of Agile EA. There may still be boxes and lines, perhaps, but the EAs must move each element, each box and line, up a level of abstraction.

Instead of a box representing a piece of technology, the box represents a self-organizing team’s dynamic choice of technology. Instead of a box representing a process, that box represents once again the result of a self-organizing team’s choice about a process.

The overall digital architecture, therefore, represents self-organizing teams’ approach to answering the basic questions about the context and content of customer journeys, rather than the context and content of those journeys themselves.

Only by working at this ‘meta’ level will the architecture ever account for the inherent agility necessary to address ever-changing customer preferences and behavior in the context of a digitally transforming organization.

The goal of EA, of course, is building business agility as a core competency across the enterprise. It’s not good enough to change, your organization must get better at change. After all, you cannot eliminate change. You cannot even simplify it. Digital architecture must embrace change.

Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credits: Willi Heidelbach and Intellyx.

Link: http://intellyx.com/2016/05/09/data-driven-agility-aus-daten-wird-geschaft/

By Urs M. Krämer

Ausblick: Big-Data-gestützte Innovationen, nicht nur Optimierung

Das Potenzial, aus dem Echtzeit-Feedback von IT-Systemen Abläufe und Geschäft zu verbessern, ist längst nicht ausgereizt. Jason Bloomberg von Intellyx beschreibt es in einem Wired-Artikel sehr anschaulich. „Does your organization, say, optimize its salaries based upon business outcomes — in real-time? Do your security policies balance the cost of security with the corresponding risk of loss, again in real-time?” Er geht aber noch einen Schritt weiter und bringt das Thema Data-driven Innovation ins Spiel. Das bedeutet: Am Ende des Digitalisierungstunnels, den Unternehmen gerade durchfahren, verbessern sie ihre Innovationsfähigkeit durch Big Data. Sie sind selbst disruptiv, als auf disruptive Veränderungen zu reagieren. Man könnte auch sagen: Wären diese Unternehmen eine Website, wären sie hoch responsive – sie liefern optimale Ergebnisse, egal wie und wie schnell sich die Anforderungen gerade verändern.

Read the entire article at http://digitale-exzellenz.de/data-driven-agility-aus-daten-wird-geschaft/

Link: https://intellyx.com/2016/06/25/transform-your-organization-with-the-inverse-conway-maneuver/

By Betica

Jason Bloomberg of Intellyx feels the rate of technology evolution in today’s business world is actually “reversing the Inverse Conway Maneuver.” Instead of companies making structural changes ahead of time in the hopes of reaching goals like DevOps or continuous deployment, the transformation is actually happening in the opposite direction.

“Technology change is driving changing customer preferences and behavior, which in turn are driving organizational change across increasingly software-driven enterprises. The causality question behind Conway’s Law, therefore, is less about how changing software organizations can lead to better software, but rather how companies can best leverage changing technology in order to transform their organizations,” says Bloomberg.

Read the entire article at http://betica.com/blog/2016/06/17/transform-your-organization-with-the-inverse-conway-maneuver/

Link: https://intellyx.com/2016/07/11/tour-the-agile-digital-transformation-roadmap/

Since we launched our Agile Digital Transformation Roadmap poster two weeks ago, several hundred people around the globe have downloaded it – but it’s not clear how many of them have taken the time to work their way through it.

Haven’t seen it yet, you say? No worries – you can download the poster for free at AgileDigitalTransformation.com.

OK then – everyone have the poster handy? Good. Here’s how to make sense of it.

So…Where’s the Roadmap?

The first thing you’ll notice about the ADT Roadmap is that it doesn’t look too much like the sort of roadmap you’d likely see in the course of your work. There are no clear starting or ending points, and while the progression generally goes from left to right, there are plenty of branches and backtracks along the way.

Welcome to digital transformation, folks! Your transformation will also likely have unclear endpoints, and you’ll find the route you’re taking to be circuitous and fraught with missteps.

Any digital transformation roadmap that purports to simplify matters and lay out a clear path would be worse than useless, as it might convey a false sense of simplicity. Don’t be fooled – we’re talking fundamental business transformation here. Expect a bumpy ride.

Ironically, the ADT Roadmap resembles a true roadmap more so than the enterprise facsimiles we run into at work – you know, the kind you used to get at a gas station (Millennials, bear with me here).

Remember, a true paper roadmap has no idea where you are or where you want to go – but it can help you find the best route if you use it properly.

Start at the Beginning

Starting points for any business transformation all have one thing in common: they represent a business with difficult problems that are causing substantial pain. After all, transformation is difficult and risky, so you’d never hazard such a challenge if you the change didn’t promise to be less risky or painful than the status quo.

On the ADT roadmap we’re rolling up all the various and sundry issues plaguing your organization into two catchalls: siloed organizations and obsolete applications. If you want to fix what’s broken, look no further than your people and your technology.

In addition to these perennial sources of pain, two other trends are driving change for digital efforts in particular: changing customer preferences and exploding quantities of data.

In fact, it’s no coincidence we put changing customer preferences in the upper left hand corner of the roadmap, as our definition of digital begins with such customer-driven change. The data explosion, in contrast, is closer to the middle of the roadmap, as the quantity and velocity of data will continue unabated as your digital transformation progresses.

Touring the Five ‘Countries’ on the Roadmap

As you traverse the roadmap you will come to five different areas, represented broadly by the colors of the background. Customer Experience, Enterprise IT, Big Data, DevOps, and Agile Architecture – not in any particular order, and with plenty of overlaps, but any digital transformation is likely to involve all five.

These five ‘countries’ on our roadmap present two overarching lessons: first, the digital story is multifaceted and complex, and it’s impossible to boil it down to either a marketing exercise or technology initiative alone. Second, much of the important work occurs at the overlaps.

In fact, beware of any digital transformation infographic that cleanly separates such areas of activity. That kind of representation would only reinforce the organizational silos that digital transformation must break down. The ADT Roadmap, in contrast, focuses more on connecting diverse efforts and emphasizing areas of overlap.

What Do We Mean by ‘Agile’?

When people see the word ‘Agile’ today, they usually think of an approach to software development. However, software development clearly isn’t the context for how the ADT Roadmap uses the word. Instead, we’re referring to business agility – the ability to respond quickly and efficiently to change, and to leverage change for competitive advantage.

Agile Architecture in particular is a phrase that confuses people, as it has two meanings as well. The most common use of this term means software architecture for Agile software projects – but as anyone who has read my book The Agile Architecture Revolution knows, what we mean by this phrase is an approach to Enterprise Architecture that drives business agility across the organization.

Given this broader notion of agile, then, the meaning of Agile Digital Transformation begins to crystallize. Digital transformation is not a process of moving to a particular ‘digital state’ for the enterprise. Rather, for organizations to be successful, they must become better able to respond to change and leverage change overall. In other words, Agile Digital Transformation requires that organizations establish change as a core competency.

The Road to Change

What does it mean, then, for a roadmap to lead an organization to establish change as a core competency? Much as the Wizard of Oz could only provide his four intrepid supplicants with tokens (as true change comes from within), so too with digital transformation. In our case, the tokens of transformation are enterprisewide horizontal self-organization, business at velocity, ‘infinite’ scale, digital on demand, and intelligent software.

None of these tokens is sufficient to guarantee successful Agile Digital Transformation either individually nor taken together, but organizations that are able to achieve them are more likely to have successfully transformed into agile enterprises.

As with any worthwhile goal, therefore, the focus should be on the journey more so than the endpoint. Just so with the ADT poster, as your path through each step will progress over time.

The Intellyx Take: And Now a Word about our Sponsors

I’m sure you haven’t missed the fact that twelve indubitably insightful vendors have coughed up their hard-earned dollars to sponsor the ADT Roadmap poster. What you might not have noticed is that with the exception of one pair, none of the sponsors compete with each other.

In fact, the variety of product offerings among our sponsors is remarkably diverse – from mainframe tools to networking technology, from enterprise architecture consulting to cybersecurity – these dozen companies represent the surprising range of technologies and services that support enterprise digital transformation.

Even the pair in direct competition in the Digital Performance Management (DPM) space – Dynatrace and SOASTA – have surprisingly little overlap in their product offerings, in spite of the fact that DPM, perhaps more than any other market segment, is central to the success of today’s enterprise digital efforts.

Our sponsors’ diversity, on the other hand, also represents one of the challenges of digital transformation. Not only can you not buy transformation itself, but it’s even difficult to identify which tools you will need to move your organization along the roadmap to Agile Digital Transformation. Our sponsors, however, are a good starting point.

Jason Bloomberg will be giving away free copies of the Agile Digital Transformation Roadmap poster at the SHARE Atlanta 2016 Conference on August 2^nd. His presentation is entitled Avoid the Bimodal Disaster.

Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, the twelve sponsors of the poster are Intellyx customers: Dynatrace, Software AG, SOASTA, Compuware, OutSystems, CC & C Solutions, Fiber Mountain, Chef Software, OpenLegacy, 2nd Watch, Loop AI Labs, and Certes Networks. Image credit: Intellyx.

Link: https://intellyx.com/2016/07/20/professional-development-webinar-software-defined-everything-includes-storange-and-data/

By Nicole Maus

Intellyx’s new Agile Digital Transformation Roadmap poster is here! The poster lays out the steps necessary for enterprises to align with customer preferences by implementing change as a core competency and features five main focus areas: customer experience, enterprise IT, agile architecture, devops, and big data.

“While digital transformation begins with a customer-focused technology transformation, in reality, it represents end-to-end business transformation as organizations establish change as a core competency,” says Jason Bloomberg, president of Intellyx and contributor to Forbes. “The Agile Digital Transformation Roadmap poster illustrates the complex, intertwined steps enterprises must take to achieve the benefits of digital transformation.”

The poster is the companion to Jason Bloomberg’s forthcoming book, Agile Digital Transformation, due in 2017. This book will lay out a practical approach for digitally transforming organizations to be more agile and innovative.

Read the entire article at http://2ndwatch.com/blog/the-agile-digital-transformation-roadmap-poster/