Welcome!

Java IoT Authors: Pat Romanski, Liz McMillan, Elizabeth White, Yeshim Deniz, Zakia Bouachraoui

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: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and G...
Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the importance of customers being able to use the specific technologies they need, through environments and ecosystems that expose their APIs to make true ...
The current age of digital transformation means that IT organizations must adapt their toolset to cover all digital experiences, beyond just the end users’. Today’s businesses can no longer focus solely on the digital interactions they manage with employees or customers; they must now contend with non-traditional factors. Whether it's the power of brand to make or break a company, the need to monitor across all locations 24/7, or the ability to proactively resolve issues, companies must adapt to...
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use of real time applications accelerate, legacy networks are no longer able to architecturally support cloud adoption and deliver the performance and security required by highly distributed enterprises. These outdated solutions have become more costly and complicated to implement, install, manage, and maintain.SD-WAN offers unlimited capabilities for accessing the benefits of the cloud and Internet. ...
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
DXWorldEXPO LLC announced today that "IoT Now" was named media sponsor of CloudEXPO | DXWorldEXPO 2018 New York, which will take place on November 11-13, 2018 in New York City, NY. IoT Now explores the evolving opportunities and challenges facing CSPs, and it passes on some lessons learned from those who have taken the first steps in next-gen IoT services.
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.