Bespoke software systems that deliver business growth
How to implement a powerful strategy for aligning your company’s IT with its Wakefield business goals through Lean software engineering. If you missed it, here is a brief overview:
“Lean is an emerging paradigm that has rejuvenated the production of automobiles and other manufactured goods worldwide. It also holds great promise in transforming how businesses develop software systems. This is especially true for companies just embarking on their Lean journeys.”
The next step after developing this new mindset is to identify the primary value streams that deliver value to your business’s customers – then tear apart these bloated process flows by working back from customer needs (the marketing department) inwards through engineering, sales, operations, and finally development to introduce the changes that remove waste.
Within this structure, your software product architects can begin to think about how to make their systems both leaner – more focused on the customer needs – and more operationally efficient through automated deployment and management. An integrated set of best practices is emerging for developing B2B e-commerce systems that is built upon established standards like SOAP and Web services.
The next step is to apply Lean thinking to technology architectures themselves with what you might call “Lean architecture” or “value stream architecture.”
This new discipline will help you optimize your IT investment by delivering value quickly while minimizing cost and risk.
The rest of this article will focus on how to do this in three key areas:
- Build systems that are loosely coupled from the start,
- Design for “continuous change,” and lastly,
- Apply a consistent management approach to your portfolio of IT investments. The good news is that applying Lean principles to your overarching technology architecture won’t just improve your business processes – it can actually bring them into being!
This is because Lean architectures share leaner characteristics at every level – from technology components down to procedures themselves. It all starts with two simple design rules:
The first rule ensures that you can quickly and easily deploy your system to meet changing business needs:
The second rule removes the need for much of what we now consider standard infrastructure:
As a bonus, you’ll find that both rules apply well beyond software systems. For example, they help keep retail supply chains lean and agile as demonstrated by Toyota’s car manufacturing operations.
Now let’s look at how these two principles work in practice. First up is designing for continuous change. Integrating Web services into your application through externalized, service-oriented interfaces dramatically reduces the friction that holds things back. For example:
The increasing availability of service-orientation and Web services standards makes it easier than ever to develop systems that we can change at any time without having to stop or restart them. This is because they allow us to separate the real world from the presentation layer behind a thin facade by defining our application’s business logic in terms of collections of cooperating entities known as services . These services will continue operating independently even if underlying data sources are modified. Thus, when one is changed, another can seamlessly take over its processing needs with no impact on other components in the system unless they too need to change.
Let’s say you like this approach and you want to make it even simpler by abandoning the presentation layer itself? After all, if we can readily change services without affecting each other, there’s no need for any of them to be “presentation-aware.” Well, think again! Eliminating the presentation layer also eliminates the ability of end-users to view or work with data. This is why most developers prefer keeping at least some user interface (UI) capabilities in their applications even if they’re not using bloated front ends that require specialized training to use. Here are some reasons why:
It takes less time for users to browse through a simple UI than it does to perform the same task by issuing service requests
It’s easier for users to discover existing data or create new records when working with a familiar UI
With some types of applications, business rules are much more easily expressed using visual tools that enable quick changes without coding
Keeping just enough presentation layer support in your application helps ensure that it remains loosely coupled from the rest. For example:
To accommodate changing needs, you don’t need to make deep changes throughout an entire system. Rather, you only have to make them where they’re needed most. This means redesigning parts of your system according to whatever principles are required to accommodate the necessary changes, while carefully avoiding any unnecessary ones.
Next, let’s look at how removing infrastructure requirements can help you save time and money. Many software projects are badly delayed because of long kick-off times where people spend too much time planning what they’re going to build rather than actually getting on with it. This is why it makes more sense to use a “spiral” approach where you start with just enough work to get things running, then gradually add new features as you progress through successive iterations . With each iteration you’ll have more customer feedback that will allow your stakeholders to better prioritize future requirements before resources become scarce or deadlines loom ever closer – both of which can force another round of difficult tradeoffs.
With this approach, the business is never left with a false impression of what’s being delivered because it gets to see what it looks like along the way. By gradually adding features, you’re able to verify that they meet requirements before moving on to the next round of development instead of after. If any requirements are found wanting then you can change them or remove them altogether with little effort because you only need to make relatively small changes each time around .
This is good for everyone involved in your project because it allows you to move forward at a predictable pace while minimizing rework and avoiding costly mistakes.
If you found this discussion thought provoking and would like to learn more then contact Wakefield Apps.