With recent software delivery processes, for example, the Agile process and Continuous Integration (CI) and Continuous Deployment (CD)of code, the DevOps approach provided a faster highway to ensure faster delivery with low risks. So the earlier SDLC model got redefined over time with Agile and then with DevOps to its current shape.

However, because design is an integral part of any product delivered, there is a need to ensure that gaps are bridged between the traditional design lifecycle and the fast track of the DevOps development lifecycle. DesOps and DevOps both are complementary to each other. The design delivery process improvements try to optimize the overall delivery process and thereby contribute to DevOps, for example, in aspects such as testing of the product that involves design aspects, usability, accessibility, etc.

The need for tighter integration between the design team and the engineering team became a necessity to ensure to design at scale. During the past two to three years, the top five big companies have made heavy investments in this area that have paved the way for other organizations and design communities to be more explorative in this area.

DesOps, aka. DesignOps, refers to an approach to design that is inspired by the culture of DevOps. In this and the following posts, we will explore, the practical approaches for

How to prepare for the next wave in design that compliments the DevOps concepts of a cultural shift, collaboration, and automation.

We will also see what solutions are available today that contribute to bringing the full circle of design in the context of the software development lifecycle.

Today, design as a discipline is getting more and more recognition across the entrepreneur world and many industry efforts, such as IBM‘s Enterprise Design Thinking framework, RedHat‘s Open Studio and similar ones, are at a large scale, trying to create a synergy between the Agile approach to the software development lifecycle and the Design Thinking. It is an interesting crossroad where the next big thing in product delivery is to bring scalability as well as automation to the creative process.

In the context of the software industry, I always see “design” as an intersection between creativity and technology where both shape each other—with help from user needs—and blend the results into successful products.

Any typical software product that is delivered involves many complex as well as divergent technologies, processes, people, and visions. Though software delivery mostly happens with team members segmented into two major groups—developers and designers—ultimately, the best outcome always depends on how the two teams communicate with each other and how efficiently their thoughts and ideas are shared, propagated, and translated.

This is part III of a three-part series describing a proposed approach for an agile API lifecycle: from ideation to production deployment. If you missed it or need a refresher, please take some time to read part I and part II.

This series is coauthored with Nicolas Massé, also a Red Hatter, and it is based on our own real-life experiences from our work with the Red Hat customers we’ve met.

In part II, we discovered how ACME Inc. is taking an agile API journey for its new Beer Catalog API deployment. ACME set up modern techniques for continuously testing its API implementation within the continuous integration/continuous delivery (CI/CD) pipeline. Let’s go now to securing the exposition.

This is part II of a three-part series describing a proposed approach for an agile API lifecycle from ideation to production deployment. If you missed part 1 or need a refresher, please take some time to read part I.

This series is coauthored with Nicolas Massé, also a Red Hatter, and it is based on our own real-life experiences from our work with the Red Hat customers we’ve met.

In part I, we explored how ACME Inc. is taking an agile API journey for its new Beer Catalog API, and ACME completed the API ideation, contract design, and sampling stages. Let’s go now to mocking.

The goal of this series of posts is to describe a proposed approach for an agile API delivery process. It will cover not only the development part but also the design, the tests, the delivery, and the management in production. You will learn how to use mocking to speed up development and break dependencies, use the contract-first approach for defining tests that will harden your implementation, protect the exposed API through a management gateway and, finally, secure deliveries using a CI/CD pipeline.

I coauthored this series with Nicolas Massé, who is also a Red Hatter. This series is based on our own real-life experience from our work with the Red Hat customers we’ve met, as well as from my previous position as SOA architect at a large insurance company. This series is a translation of a typical use case we run during workshops or events such as APIdays.

Last Sunday, I returned home, India, after attending a series of collaborative sessions in Raleigh, NC, with many designers and developers across Red Hat and the open-source community, at the UX Summit and the PatternFly Conference. The whole experience was inspiring, informative and at the same time thought provoking with many takeaways, out of which the most interesting for me was that cumulatively all the inspiring talks from the speakers of the conference were implicitly hinting towards a clue. How our attempt to solve the existing technical solutions also impact the existing work process and thereby demand a rethink on the process blocks we use.

Continue reading “The Evolution of Technology in the Context of Software Development & Design Process: Take-away from PatternFly Conference”