Welcome!

Microservices Expo Authors: Elizabeth White, Liz McMillan, Derek Weeks, Pat Romanski, Karthick Viswanathan

Related Topics: @CloudExpo, Java IoT, Microservices Expo, Linux Containers, Containers Expo Blog, @DXWorldExpo

@CloudExpo: Article

What We Really Mean by Digital Transformation

Agile Architecture is the key to Digital Transformation

Want to know a secret? I loathe the phrase Digital Transformation. Not only is the word Digital silly and misleading, but Transformation ain’t much better. The mere act of naming a business initiative Digital Transformation suggests to people that once the transformation is complete, we’ll be done. Look at us! We’re Digitally Transformed!

Hogwash. A single transformation is better than nothing, but what we really want is the ability to transform our business as needed. Furthermore, we need to be agile with our transformation initiative itself. The last thing we want is to institute, say, a three-year transformation effort, only to find at the end of the three years that the world changed a year into the initiative, rendering it a useless waste of money and effort.

So, who are the right people in the organization to address this sorry state of affairs? Driving the change needed to make our organizations more successful at such ongoing transformation should ideally fall to the Enterprise Architects. Unfortunately, the way Enterprise Architecture (EA) is done today falls well short of this mark.

Traditional EA starts with documenting the initial state of an enterprise. Then Enterprise Architects document the final state as required by the business. Finally, they help the organization plan how to get from one state to the other.

There are only three things wrong with this way to think about EA: The initial state. The final state. And yes, the plan to get from one to the other. It’s no wonder most organizations who were fool enough to sink money into EA believe EA is completely broken. Even EAs think EA is broken, and they do it for a living!

But no matter how fun it is to bemoan this sorry state of affairs, this Cortex must help point the direction to a better way of thinking about – and doing – Enterprise Architecture. The success of any Digital Transformation effort hangs in the balance.

What’s Wrong with Point A to Point B?
It seems so intuitive that the way to solve a problem is first, understand the problem, second, understand the solution, and third, solve the problem. Unfortunately, many EA initiatives don’t get past step one. Documenting the initial state of an enterprise – or even simply documenting the initial state of an enterprise’s IT environment, which is usually where EAs focus their efforts – is an exercise in futility. There are simply way too many bits and pieces, moving parts made of people and technology, for such an activity to ever complete, let alone provide sufficient detail to add clarity to the situation. Remember, the organization is always in flux. Even if you could take a snapshot of everything, it would be out of date a moment later.

What about the final state? That’s the nirvana situation where all your problems are solved, right? OK, raise your hand if there was ever a time in your career where all the problems were solved, all the bugs were fixed, all the projects were complete. Anybody? Sounds rather unrealistic, wouldn’t you say? Even if you narrow your scope to a single aspect of your business or even a single project, there is nothing final about a final state, if you could even refer to such an implausible scenario as a state, which is asking a lot. Remember, everything is connected to everything else, and everything is always changing. The notion of a “final state” is an unrealistic simplification that misleads people into thinking the approach they’re taking will actually solve problems.

Very well, let’s say you’ve still reading, in spite of thinking my comments on initial and final state are a bunch of hogwash. Certainly, you may ask, the EAs can at least concoct some kind of plan for getting from point A to point B? Sorry to disappoint. If what you mean by a “plan” is a description of the steps you must take that you can put together before you take those steps, then no. You’ll never come up with such a plan that ends up having any relationship to reality by even the halfway mark. There are simply too many unknowns, and too many things can change along the way.

Moving Up a Level
The core problem with this traditional approach to architecture is that it is simply too literal. It deals with things as they are and things as you desire them to be, without dealing with the fact that everything is subject to change. But the good news is, we architects have a wonderful tool in our box of tricks for dealing with excess literalness: the tool of abstraction. If we move up a level of abstraction, we’re no longer thinking about initial and final state. Instead, we’re thinking about moving from being less agile to being more agile.

Literal-minded thinkers (and I know you’re out there) will be protesting at this point that “being less agile” is our initial state and “being more agile” is our final state, so we’re just playing word games. And if you squint and hold your nose, there is a minuscule portion of truth in that overly literal perspective – but you’re missing the point here. “Being less agile” describes any number of possible initial states we may find ourselves in, and “being more agile” means being able to deal with change better, no matter which state we started at or where we happened to end up.

Put another way: moving from A to B describes a change (or actually, a set of changes) in the organization. Moving from less agile to more agile describes a change in how the organization deals with change, from being less able to deal with change to being more able to deal with change. In other words, we’re now thinking at the Meta level. We’re not doing architecture any more, oh no. We’re doing meta-architecture: we’re architecting our architecture.

Introducing the Bloomberg Agile Architecture™ Maturity Metamodel
Time to put some meat on these bones. As I’ve explained before, the Bloomberg Agile Architecture (BAA) Technique is a particular approach to implementing EA that is business agility driven. It’s not a framework you need to subtract from but a technique that complements other architectural efforts. Today I’m rolling out a core BAA artifact: the BAA Maturity Metamodel.

Try as I might, I couldn’t fit the entire chart into this article, so instead, I’ve linked to a pdf version of the Metamodel. Click here or the image below to download the pdf.

Unfortunately, there isn’t room in this Cortex to fully explain the BAA Maturity Metamodel (for that, take one of our classes to learn all the details, or drop me a line). But there is room here for a few of the highlights.

First, notice the four levels: Chaotic State, First-Gen SOA/Centralized, Next-Gen SOA/Cloud-Centric, and Agile Architecture. These designations refer to the organization’s context for architecture as it matures from less agile to more agile. In other words, it maps how your architecture is evolving – and thus the chart represents an aspect of your meta-architecture.

Second, note the twelve dimensions (rows), sorted neatly into four areas: Organization, Process, Information, and Technology. This organization of dimensions is more a matter of convenience than anything else. Feel free to rearrange the dimensions as you see fit.

In fact, feel free to change anything in the metamodel you see fit, based upon your situation – and always be willing to change it as your architecture evolves. Remember, there are two sides to being agile: the core driver of business agility (increasing in the metamodel from left to right) and the fact that BAA is Agile in approach (in other words, generally follows the principles of the Agile Manifesto). And as ye old Manifesto sayeth, thou shalt respond to change over following a plan. Even if the plan is to be Agile!

Finally, never forget what this diagram is for. It’s for helping architects coordinate change across the organization as driven by business needs. The metamodel – or any other aspect of the architecture – never tells the business what it should do. In the immortal words of a well-known sage: “business needs drive the architecture, and architecture drives the technology. Never let technology drive the architecture or the architecture drive the business.” Couldn’t have said it better myself.

The Intellyx Take
I know that many of you who took the time to download the Maturity Metamodel will have many questions about it – and over time, I’ll get to the answers. But just to whet your appetite a wee bit further, let’s take a moment to discuss the first dimension: Business Transformation.

The starting point for business transformation, of course, must be “no transformation.” As the organization gets a handle on their architecture and moves to first-generation SOA, IT moves into the role of service provider – not simply IT services, but also Web Services that automate the interaction with existing systems of record. Instead of simply integrating those systems, now the IT organization publishes interfaces that can be consumed as needed, transforming the relationship between IT and the business (which was always easier said than done, hence the relegation of first-generation SOA to Level One).

As the architecture matures to next-generation, Cloud-friendly SOA (which in many cases loses the “SOA” name, but is Service-oriented nevertheless), the transformation story centers on the move to the Cloud. Cloud Computing, you see, is far more than a change in technology deployment. It represents a force for transforming the business.

But even Cloud-driven transformation isn’t the end of the story. The move to Agile Architecture is a move to continuous business transformation – where the organization is as agile as it wants to be, and is able to deal with change as a routine part of how it does business. Continuous business transformation, of course, has always been the center of the Agile Architecture story – and is what we really mean when we say we want Digital Transformation.

More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).

@MicroservicesExpo Stories
The dynamic nature of the cloud means that change is a constant when it comes to modern cloud-based infrastructure. Delivering modern applications to end users, therefore, is a constantly shifting challenge. Delivery automation helps IT Ops teams ensure that apps are providing an optimal end user experience over hybrid-cloud and multi-cloud environments, no matter what the current state of the infrastructure is. To employ a delivery automation strategy that reflects your business rules, making r...
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex ...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
Admiral Calcote - also known as Lee Calcote (@lcalcote) or the Ginger Geek to his friends - gave a presentation entitled Characterizing and Contrasting Container Orchestrators at the 2016 All Day DevOps conference. Okay, he isn't really an admiral - nor does anyone call him that - but he used the title admiral to describe what container orchestrators do, relating it to an admiral directing a fleet of container ships. You could also say that they are like the conductor of an orchestra, directing...
The past few years have brought a sea change in the way applications are architected, developed, and consumed—increasing both the complexity of testing and the business impact of software failures. How can software testing professionals keep pace with modern application delivery, given the trends that impact both architectures (cloud, microservices, and APIs) and processes (DevOps, agile, and continuous delivery)? This is where continuous testing comes in. D
SYS-CON Events announced today that Synametrics Technologies will exhibit at SYS-CON's 22nd International Cloud Expo®, which will take place on June 5-7, 2018, at the Javits Center in New York, NY. Synametrics Technologies is a privately held company based in Plainsboro, New Jersey that has been providing solutions for the developer community since 1997. Based on the success of its initial product offerings such as WinSQL, Xeams, SynaMan and Syncrify, Synametrics continues to create and hone in...
You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know that not all workloads are suitable for cloud. You know that you want the kind of ease of use and scalability that you get with public cloud, but your applications are architected in a way that makes the public cloud a non-starter. You’re looking at private cloud solutions based on hyperconverged infrastructure, but you’re concerned with the limits inherent in those technologies.
Gone are the days when application development was the daunting task of the highly skilled developers backed with strong IT skills, low code application development has democratized app development and empowered a new generation of citizen developers. There was a time when app development was in the domain of people with complex coding and technical skills. We called these people by various names like programmers, coders, techies, and they usually worked in a world oblivious of the everyday pri...
The notion of improving operational efficiency is conspicuously absent from the healthcare debate - neither Obamacare nor the newly proposed GOP plan discusses the impact that a step-function improvement in efficiency could have on access to healthcare (through more capacity), quality of healthcare services (through reduced wait times for patients) or cost (through better utilization of scarce, expensive assets).
The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Microservices being modular these are faster to change and enables an evolutionary architecture where systems can change, as the business needs change. Microservices can scale elastically and by being service oriented can enable APIs natively. Microservices also reduce implementation and release cycle time and enables continuous delivery. This paper provides a logical overview of the Mi...
The “Digital Era” is forcing us to engage with new methods to build, operate and maintain applications. This transformation also implies an evolution to more and more intelligent applications to better engage with the customers, while creating significant market differentiators. In both cases, the cloud has become a key enabler to embrace this digital revolution. So, moving to the cloud is no longer the question; the new questions are HOW and WHEN. To make this equation even more complex, most ...
Some journey to cloud on a mission, others, a deadline. Change management is useful when migrating to public, private or hybrid cloud environments in either case. For most, stakeholder engagement peaks during the planning and post migration phases of a project. Legacy engagements are fairly direct: projects follow a linear progression of activities (the “waterfall” approach) – change managers and application coders work from the same functional and technical requirements. Enablement and develo...
Some people are directors, managers, and administrators. Others are disrupters. Eddie Webb (@edwardawebb) is an IT Disrupter for Software Development Platforms at Liberty Mutual and was a presenter at the 2016 All Day DevOps conference. His talk, Organically DevOps: Building Quality and Security into the Software Supply Chain at Liberty Mutual, looked at Liberty Mutual's transformation to Continuous Integration, Continuous Delivery, and DevOps. For a large, heavily regulated industry, this task...
For DevOps teams, the concepts behind service-oriented architecture (SOA) are nothing new. A style of software design initially made popular in the 1990s, SOA was an alternative to a monolithic application; essentially a collection of coarse-grained components that communicated with each other. Communication would involve either simple data passing or two or more services coordinating some activity. SOA served as a valid approach to solving many architectural problems faced by businesses, as app...
Many IT organizations have come to learn that leveraging cloud infrastructure is not just unavoidable, it’s one of the most effective paths for IT organizations to become more responsive to business needs. Yet with the cloud comes new challenges, including minimizing downtime, decreasing the cost of operations, and preventing employee burnout to name a few. As companies migrate their processes and procedures to their new reality of a cloud-based infrastructure, an incident management solution...
Gaining visibility in today’s sprawling cloud infrastructure is complex and laborious, involving drilling down into tools offered by various cloud services providers. Enterprise IT organizations need smarter and effective tools at their disposal in order to address this pertinent problem. Gaining a 360 - degree view of the cloud costs requires collection and analysis of the cost data across all cloud infrastructures used inside an enterprise.
Our work, both with clients and with tools, has lead us to wonder how it is that organizations are handling compliance issues in the cloud. The big cloud vendors offer compliance for their infrastructure, but the shared responsibility model requires that you take certain steps to meet compliance requirements. Which lead us to start poking around a little more. We wanted to get a picture of what was available, and how it was being used. There is a lot of fluidity in this space, as in all things ...
Cloud Governance means many things to many people. Heck, just the word cloud means different things depending on who you are talking to. While definitions can vary, controlling access to cloud resources is invariably a central piece of any governance program. Enterprise cloud computing has transformed IT. Cloud computing decreases time-to-market, improves agility by allowing businesses to adapt quickly to changing market demands, and, ultimately, drives down costs.
Recent survey done across top 500 fortune companies shows almost 70% of the CIO have either heard about IAC from their infrastructure head or they are on their way to implement IAC. Yet if you look under the hood while some level of automation has been done, most of the infrastructure is still managed in much tradition/legacy way. So, what is Infrastructure as Code? how do you determine if your IT infrastructure is truly automated?
Every few years, a disruptive force comes along that prompts us to reframe our understanding of what something means, or how it works. For years, the notion of what a computer is and how you make one went pretty much unchallenged. Then virtualization came along, followed by cloud computing, and most recently containers. Suddenly the old rules no longer seemed to apply, or at least they didn’t always apply. These disruptors made us reconsider our IT worldview.