Over a number of years, I have had the opportunity to conduct several architectural assessments on SOA, ROA and API Management. The domains and technology stacks have varied, and the engagements have been a mix of post mortems and organizational readiness. What I have found is that there are certain common characteristics of organizational behavior and challenges that emerge. In this article I consider a few of these findings and provide some recommendations for a practical ROA solution.
I’ll start with two mutual and typical assessment findings.
- The proliferation of agile concepts, rather than a practical implementation of the principles.
- Architectural roadmaps and bridging the strategic plan into tactical implementations.
These are areas where some organizations have thrived, while many others have struggled. For example in the agile category, it’s not unusual to hear the conceptual and fundamental speak throughout the organization. While the practical application of agile project management approach is often wanting in project execution. In some cases political ideology is the root cause.
At risk of sounding like a fundamentalist; I have found that organizations that make it a matter of importance to distinguish between what are agile principles, and a well-reasoned implementation of an agile based project management framework, do find that change and adoption is more effective and prevalent. And helps move the organization organically toward maturity.
For example, organizations that start with clear objectives and measures for a disciplined and framework guided approach to Scrum and Scrumban, do experience the benefits of agile. Also, if your organization using a high tech tool, there are a couple of good practices. First have a minimal design model of the issue types and relationships, which are validated by a Scrum Master. Second, pair the tool administrator with a Scrum Master during for configuration / implementation and testing.
The risks that are often realized in agile thinking organizations, become issues around the ambiguity of the disciplined use, expected inputs, outputs or reports and target consumers of a Scrum, Kanban, or Scrumban framework. The goal of adopting these frameworks, is not a wholesale implementation of the framework, but to tailor the framework to the current organization capabilities, with a clear intent to iterate the approach and to engage in continuous improvements. And above all, avoid Bikessheding around semantics of framework definitions.
One technique could include; starting with a low tech Scrumban approach, and track Architectural Epics, Features and Stories. Use a quality check list in sprint planning that states that when an Epic or Story is complete. Generally, this is measured by a assigning business values, and reasonable acceptance criteria. I’ll tie these two attributes to the assessment findings in the next topic in the blog. I have also found that redefining well documented terms of a framework typically hinders adoption, and often generates needless confusion. The recommendation here is; if you want Burndown charts, or time on task tracking. Then explicitly state these as design requirements for implementing the framework.
The second related topic concerns the evaluation of Architectural roadmaps. It is not uncommon to find a couple of distinctive organizational behaviors.
- A generalized perception at the program and project execution level, that strategic goals must be sacrificed for tactical needs.
- That enterprise level architectural concerns are nice to have, but they slow down the development effort.
The post mortem for many engagements shows that these prevailing attitudes have led to many so called practical / tactical approaches that have produced the “accidental architectures” that are stifling organizational agility today. What is most conspicuous is that there is often a defacto perception that the adoption of strategic technologies are the root cause. However, as it was in the nascent days of SOA, and its resulting era. The idea and promise that emerging vendor platforms and technology stacks can alone solve the new organization challenges for agility and implementing new integration patterns could easily yield the same story going forward. A recommended good practice for this scenario is to input strategic goals as Epics and decomposed Features with linked Stories into the Scrum life-cycle. Here is where business value assignment, and acceptannce criteria can drive the importance and priority of architectural decisions. So later you can inspect what you expect.
For example, REST as an architectural style, and microservices as an architectural design pattern, combined with disruptive innovations are changing the game for integration and agility. And there are certain fundamental underpinnings that should not be overlooked. Namely a clear set of architectural goals with derived quality measures.
For example, for microservices as a design approach should have minimally these goals.
- The simplification of application configuration, using a number of tools for provisioning machines.
- Provide a means for a seamless Continuous Delivery model.
- Fault tolerance services, with graceful failure, and minimal disruption to the system.
- Minimize downtime at deployment.
- Consistency of the environment across delivery; Dev to Prod releases.
These architectural goal are the drivers for your objectives, business value, quality check list and success criteria for architectural Epics, Features, Spikes and Stories. These are practical concerns that are technically agnostic, rather than enterprise level architectural principles. From an agility perspective these goals and the resultant success criteria should be attached to items the program, and or project management backlog. I have found that an architectural Scrumban is an effective way to manage this work. Primarily because goals and qualities transcend discreet projects. And using this approach gives distinct visibility to architectural Features, and enables Stories or Spikes to be added to a development Sprint, or managed as an independently Scrum if needed. This enables an agile means for addressing strategic goals in the development life-cycle.
For example, one characteristic of the “accidental architecture” is technology proliferation. Using a Scrumban approach, an organization can reason about their cross cutting infrastructure concerns, and the related technology stacks which enable.
- Service Discovery
- Monitoring and Debugging
- Deployment
- The Build pipeline tools
- Logging
Because the landscape of technologies for infrastructure is continuing evolving with new capabilities. It’s important that organizations that are striving for agility apply appropriate constraints, capture lessons learned in sprint reviews, and make reasoned decisions on their architectural evolution. This again positions the strategic roadmap into tactical implementations. This also enables an agile placement of enterprise architecture concerns in preview of product managers, solution and application architects. From a microservices perspective these decisions should not be where a “free for all” approach should be taken.
On the other hand, microservices approach will enable significant flexibility in programming models and choice of technologies. In this case there are several quality attributes that should drive the “acceptance criteria” of a microservice application. These attributes were gleaned from a very good blog on microservice design. http://nordicapis.com/microservice-showdown-rest-vs-soap-vs-apache-thrift-and-why-it-matters/
- A microservice development is timeboxed and should be delivered within a sprint.
- A microservice is developed and tested independently.
- A microservice is never changed after being deployed. If new functions are required a new microservice component is created. There should not be any cost of maintenance.
- The first project that uses the microservice pays for the development. Reuse is not a business justification for microservices.
- Microservice granularity is contained within the intersection of a single functional domain, a single data domain and its immediate dependencies, a self-sufficient packaging and a technology domain.
These are qualities that belong in the application architecture space, and are useful for Scrum teams to derive acceptance criteria, as well providing a good foundation for assessing the design objectives of Features in a microservice implementation. As Business Epics are decomposed into Features and then into Stories in the grooming and planning phases, Scrum teams can use these as guidelines for reasoning about their design choices and completeness.
ROA is not an evolution of SOA. It is an architectural style with its own constraints, and architectural design patterns. Additionally, there are a wide range of technology choices to support these approaches.
However, the lessons learned from architectural assessment techniques for evaluating SOA are very much applicable to this new paradigm in integration and API service development. Primarily because there are many principles that transcend architectural styles. Regardless the current state of your organizational journey in service development. It’s a matter of due diligence, and good practice to assess your capabilities in terms of people processes and technologies for ROA. For more information on Perficient’s Integration and API practice. http://www.perficient.com/Business-Optimization/Integration
