The Cloud Architect: A Necessary Evil?
Why is the role of “Cloud Architect” necessary now, but destined to be short-lived?
Join the DZone community and get the full member experience.Join For Free
The title “Architect” is a problematic one, as there are Data Architects, Infrastructure Architects, Application Architects, Technical Architects, Enterprise Architects (EA), and many, many more. However, as the drive to Modern (i.e., Cloud) Architectures continues, we are now seeing references to “Cloud Architects”. This title seems to be a necessary evil, as the move to cloud-based architectures is inevitable. Thus, “Cloud Architect” is destined to be a temporary designation, but a necessary one for now.
Louis-LÃ©opold Boilly [Public domain], via Wikimedia Commons
What’s Makes Cloud Application Architectures Different?
Architects (of all kinds) had been focused on on-premises-based applications with a small component of the portfolio being SaaS or cloud-based. However, over the past two years or so, this has rapidly shifted to include multiple clouds, IoT-scale data, mobile apps, and next-generation analytics. Taken together, this expansion has increased the pressure for Architects to now focus more on Enterprise-wide thinking, as both the size, scale, and breadth of componentry has exploded to include many services that are no longer under the direct control of the Architect.
Unfortunately, traditional EA competencies (software design, integration patterns, security perimeters, SLDC) have not adequately prepared Architects for this shift. Independently, the sheer reduction in cycle times, as well as the increased security “attack surfaces” that these modern approaches enable (weeks/months vs. quarters/years), require a new approach. “Cloud” Architects must have a direct line of sight between the specific business success outcomes that their Lines of Business (LOBs) are requesting and the ever-expanding palette of components at their disposal.
Also, the line between solutions and their implementations is blurring. Enterprises cannot effectively absorb a continual release tempo for a good reason: their processes and applications are iterating at the same time.
So, in addition to the requisite new technology skills (Big Data, Microservices, API Management) needed, new business skills are also becoming essential. These include:
Traditional EA Focus
“Modern Architecture” Focus
Big design up front
Heavy SDLC with lip service paid to “agile”
True Agile facilitation (emphasis on MVPs / backlog
Priorities tied to annual budget cycles
Application Portfolio as the focal point for priority-setting
Finding the Silver Lining
The challenges faced by Cloud Architects are amplified by methodologies that are simply unable to keep up with the expansion in capabilities described above. Specifically, heavyweight methodologies and frameworks including TOGAF, Zachman and FEA, while useful constructs when initially designed, have often led to disconnects between the LOBs and IT decision makers. Specifically, the historical emphasis on artifacts has tended to overshadow, the more important and valuable focus areas of the portfolio, desired business outcomes, and capability traceability. This is especially true in large EA teams.
Heavyweight EA frameworks are not the only problem, however. It is also clear that some long-standing approaches have also failed to keep up with the cloud. For example, architects have literally spent decades in building SOA-based solutions. Again, while these efforts have been useful in modernizing application architectures and adopting loose-coupling contract-first thinking, they have also had mixed effectiveness at best, as “costs are higher, projects take longer, and systems are more fragile than ever.”
On the bright side, however, “service-orientation is indeed a prerequisite for rapid integration of data and business processes; it enables situational development models, such as mashups; and it’s the foundational architecture for SaaS and cloud computing.” One of the most useful design offshoots of SOA is the notion of “bounded context”, or ways to allow variations in application vocabulary across teams while using context maps to bridge the variations. Bounded context is a stepping stone that can enable independence and resiliency when designing micro service-based and other “composable” Modern Architecture patterns.
Successful architects in the cloud age also need to work closely with application teams to continually consider new structures. For instance, we have seen agile / scrum teams pivot to “feature teams” (vs. component teams) in order to better mesh the needs of the business and continue to simultaneously drive speed and alignment.
Example of "Bounded Context"
Pivoting from Patterns to Performance
So, what are some concrete steps that Enterprise Architects need to take to break out of ineffective patterns and pivot to Cloud Architectures? Here are four steps to challenge your current thinking:
- Use the Portfolio as a “heat map”: Taking a hard look at the current set of in-flight projects and programs is a great way of driving a conversation around outcomes. Specifically (and using the capabilities “lens”), mapping capabilities and, more importantly, gaps, to the portfolio will surface challenges in the current application set. Next, overlaying a technology maturity model (i.e., R&D, Leading Edge, State of the Art, Mature, Obsolete) and your Enterprise technology strategy can form a “heat map” of technical areas to consider. From there, you can decide which applications need to be retired, which need to be refactored (using cloud technologies if appropriate), and which areas are ripe for disruption or adoption of new technologies. The obvious key is the conversation across capabilities, the portfolio, and the technologies themselves – this reinforces transparency, urgency, and smart use of resources.
- Find a Champion in Pain: While not always the historical modus operandi for Enterprise Architects, understanding specific business challenges that can be solved through technology (and/or tied to the target business operating model) immediately provide a joint win strategy for the Cloud Architect and the LOB. Tap your network of LOB Champions and find a small set of achievable candidate pain points – some examples include:
- Gaps in visibility in business insights due to a merger/acquisition: How can data be more quickly assembled to drive visibility?
- Service Level challenges in field service or sales: How can process and data be made more consumable by mobile users?
- Competitive pressures in the supply chain: Can IoT and metadata be combined to quickly provide tracking / alerts at key process points?
- Rethink the notion of MVP and services: Take the pain point and design a rapid MVP around it, but focus on rapid delivery achieved through a composability-based approach. Specifically, assemble your solution using metadata, micro services and/or data-by-reference (i.e., OData). Take for example, the supply chain case listed above. One MVP could involve a pilot to combine one more of the areas below. A ruthless focus on the shortest path to such an MVP will further identify a way forward and keep the champion engaged.
- CRM data (extended via metadata)
- Elastic compute resources (linked by Microservices)
- Sensor data (accessed via a REST endpoint)
- ERP data (surfaced via OData) A ruthless focus on the shortest path to such an MVP will further identify a way forward and keep the champion engaged.
- Face your Gaps: Based on your results, identify the weak points in your ability to execute on larger cloud architecture programs by identifying major gap areas:
- Technical – tools, patterns, legacy systems, cloud vendor(s)
- Organizational – identifying champions, use cases, measures
- Process – SDLC, change management, governance
- Self-Examination – as an Architect, take a hard look at your emerging role, your recently-completed projects, new skill sets acquired, and your own personal roadmap
It is clear that both Architects and Enterprises are on journey to the cloud; multi-disciplinary learning is challenging, but necessary for sustained success.
Becoming a true “Cloud Architect” is much more than simply migrating applications to a SaaS model. Clearly a transitional role, it is more accurately described as the next generation of an Enterprise Architect by revamping the application portfolio through Cloud techniques and technologies. In addition, it exposes technical, organizational, and process gaps that have frustrated the LOB-IT partnership for decades.
Finally (and most importantly), it removes excuses and barriers between LOB and IT by providing both the raw speed and the right amount of nimbleness to react to today’s unpredictable demands and business events.
 Op. cit., martinfowler.com.
Opinions expressed by DZone contributors are their own.