Welcome!

Government Cloud Authors: Elizabeth White, Pat Romanski, Dana Gardner, Liz McMillan, Gopala Krishna Behara

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

@CloudExpo: Article

The Other Agile Architecture

Building software in an Agile way doesn’t guarantee the software will be agile

Ever since my new book, The Agile Architecture Revolution hit the streets, I've been following the keywords "Agile Architecture" on Twitter. Sure enough, there are plenty of conversations on Agile Architecture - but to my disappointment, most of them aren't about my book, or even what I mean by "Agile Architecture" in my book.

The focus of my book is on architectural approaches to delivering business agility for the enterprise - in essence, taking Enterprise Architecture (EA) to the next level, where constant business transformation is the goal, rather than a fixed end-state. The more common definition of Agile Architecture, however, is applying Agile (Agile-with-a-capital-A) principles to software architecture - a very different perspective.

I discuss the Agile Manifesto in the book, of course - I could hardly put the word Agile in the title without doing so - but these two definitions of Agile Architecture are quite different. However, it's not a question of which is right and which is wrong. Rather, the central question of this ZapFlash is how the two senses of Agile Architecture are related to each other.

Agile Software Architecture
Agilemodeling.com
is a great resource for learning the basics of Agile Software Architecture. There is far more detail there than we can cover here, but in summary, here's how ZapThink interprets the principles of Agile Architecture, according to this site:

  • Everyone on the software team can pitch in and improve the architecture, just as everyone is responsible for all the code in a traditional Agile project. However, not everyone on the development team is equally competent at software architecture, so there should be an owner of the architecture in case of disagreements.
  • Avoid ivory tower architectures, where the architects handing down architecture artifacts from on high rather than being directly involved in development, through constant feedback among architects, developers, and the rest of the team.
  • Don't overdo the architecture. Simple software requires simple architectures which don't require complicated architectural efforts. Even a doghouse needs a plan, but it's vastly simpler than the plan for a large building.
  • Architecture helps Agile software scale, which also means that architecture helps Agile software be more Cloud friendly.
  • Base your architecture on the requirements for your software. Solicit active stakeholder participation, as with any Agile project. Think about future possible requirements, but don't overbuild in anticipation of as-yet undefined needs. In other words, defer commitment on design decisions.

All of the above principles follow basic common sense, and any development team that follows them is bound to have better architected software. But thinking about Agile Architecture as an approach to architecting software leads to a central paradox: building software in an Agile way doesn't guarantee the software will be agile, as we discussed in a ZapFlash in May 2012. The fundamental problem: requirements continue to evolve, but even the most Agile of software development approaches builds to the current requirements. In fact, the final bullet above even exhorts the development team to avoid overbuilding.

We've written about the overbuilding trap before in a pair of blog posts. If we simply demand the developers build code to meet future requirements, without specifying what those requirements might be, we've just sent them down a rabbit hole. Fundamentally, if you look at the problem of building software that provides business agility as nothing more than how to build software to meet future requirements, you'll never find your way out of this hole.

How, then, do we get out of this pickle? How to we build software that responds to changing requirements, without overbuilding our software? Agilemodeling.com discusses the notion of change case modeling, where change cases describe potential new or changed requirements for a software system. In fact, ZapThink has been discussing change case modeling since we introduced the Agility Model back in 2008, although the change cases we discussed go beyond a particular software system to include processes, policies, and other elements of the Enterprise Architecture.

Solutions vs. Tools
The enterprise context for software development focuses on solutions: the stakeholder has a problem, so you build a solution to that problem. Hence when the problem changes, you need a new or different solution. However, not all software development focuses on solutions. For example, many software vendors build and sell software tools.

The most important feature of a tool is that you can use it for different things, even when it is fit for a particular purpose. Even if you limit your hammer to only hammering nails, you can still hammer many different kinds of nails into many different materials, and the hammer manufacturer doesn't have to know any of the specifics. So too with software tools. A software vendor who publishes, say, an Integrated Development Environment (IDE) need have no knowledge about the type of software that users of that IDE might use it for. The tool may be fit for certain types of development, but it's entirely agnostic as to the code its users call upon the tool to build.

The overbuilding problem tends to rear its ugly head when development teams should be building a tool, but focus on building a solution instead. Now it seems that every nail requires a different kind of hammer, where you should really be focusing on building a versatile hammer in the first place. This mistake is very common on SOA initiatives when the SOA team is trying to sort out the agnostic context for its Services: which Services are built for particular purposes (i.e., solutions) vs. Services built for reuse (in other words, tools). After all, the whole idea behind a reusable Service is that it is agnostic with respect to how people might use it in the future, a characteristic such Services share with hammers or any other kind of tool.

Declarative Programming: Configuration over Code
The primary technique software tool vendors use to support different customer requirements with the same tools is to allow customers to configure the tools to meet their needs. In other words, separate the configuration from the code, where the configuration consists of metadata that describe how the software should behave, and the code reads the config files and behaves the way the config files say to behave.

Creating such a configuration file is a classic example of declarative programming. Describe how the software is supposed to work without having to delineate the control flow that instructs the underlying processor what to execute. Declarative programming has been around for years, of course; SQL and HTML are two familiar examples of languages that support this approach. When you write SQL, you expect your database management system to understand it and behave accordingly. Similarly, writing HTML instructs your browser how to behave, while coding the software for the browser itself takes place independent of the Web pages it will be expected to render.

Unfortunately, while declarative programming separates configuration from code, not all configuration leads to agility. After all, dinosaur enterprise application packages like ERP have been configurable for years, but simply separating the behavior of the software from the underlying code is no guarantee of agility, just as defining the behavior of a Web Service by specifying its Service contract in WSDL and XSD files doesn't guarantee the Service will be reusable. Something is still missing from this picture.

To see what's missing, let's take an example of a software-based tool that does provide business agility: Amazon's IaaS tools (or any other Cloud provider's tools that rise to Amazon's standard). The coding wizards back at Amazon HQ have built interfaces that allow anyone with a credit card to provision and configure all manner of compute resources, without ever having to monkey around with the underlying code that makes the Cloud magic work. Supporting declarative configuration is merely the price of admission here. What the Cloud has done is connect people and process to the technology, empowering end users to handle the configuration themselves.

In the enterprise context, then, the missing piece of Agile Software Architecture is Agile Enterprise Architecture, where EA brings together the organization, the processes, the technology, and the information in a consistent, business-driven whole. Configurability alone doesn't provide this consistency. Instead, true Agile Architecture - that is, architecture that supports the business agility requirement - must tie these concerns together using a balanced combination of Enterprise Architecture, governance, and Agile Software Architecture.

ZapThink Take
In the Cloud example above, Cloud users may interact with the Cloud via a browser-based user interface, or they may choose to use the Cloud's APIs. APIs are unquestionably an important part of the Cloud story, but the mere fact we're calling them APIs - application programming interfaces - belies their significance. Turning the Cloud into a massive piece of software we have to program will defeat the agility benefit the Cloud provides, after all.

Fortunately, today's APIs are misnamed. We moved from tightly coupled procedure call interfaces (which were truly APIs) to contracted interfaces we called Services to the interfaces we have now, which we once again call APIs. But just as a Cloud API should provide a declarative, scriptable interface to the same capabilities the browser-based user interface exhibits, today's modern APIs should be user-empowering interfaces.

The movement toward Hypermedia-Oriented Architecture, what some people call REST, is part of this story. Remember, the programmable Web is meant to make software more Web-like, rather than make the Web more programmable. We have all the pieces of Agile Architecture: Agile Software Architecture; declarative, configuration-based programming; hypermedia-based APIs; and Enterprise Architecture to tie everything together. All we need to do know is get the architecture right.

Photo credit: Nadya Peek

More Stories By Jason Bloomberg

Jason Bloomberg is a leading IT industry analyst, Forbes contributor, keynote speaker, and globally recognized expert on multiple disruptive trends in enterprise technology and digital transformation. He is ranked #5 on Onalytica’s list of top Digital Transformation influencers for 2018 and #15 on Jax’s list of top DevOps influencers for 2017, the only person to appear on both lists.

As founder and president of Agile Digital Transformation analyst firm Intellyx, he advises, writes, and speaks on a diverse set of topics, including digital transformation, artificial intelligence, cloud computing, devops, big data/analytics, cybersecurity, blockchain/bitcoin/cryptocurrency, no-code/low-code platforms and tools, organizational transformation, internet of things, enterprise architecture, SD-WAN/SDX, mainframes, hybrid IT, and legacy transformation, among other topics.

Mr. Bloomberg’s articles in Forbes are often viewed by more than 100,000 readers. During his career, he has published over 1,200 articles (over 200 for Forbes alone), spoken at over 400 conferences and webinars, and he has been quoted in the press and blogosphere over 2,000 times.

Mr. Bloomberg is the author or coauthor of four books: The Agile Architecture Revolution (Wiley, 2013), Service Orient or Be Doomed! How Service Orientation Will Change Your Business (Wiley, 2006), XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996). His next book, Agile Digital Transformation, is due within the next year.

At SOA-focused industry analyst firm ZapThink from 2001 to 2013, Mr. Bloomberg created and delivered the Licensed ZapThink Architect (LZA) Service-Oriented Architecture (SOA) course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, which was acquired by Dovel Technologies in 2011.

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), and several software and web development positions.

IoT & Smart Cities Stories
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...