Posted on

The Mindset of an Impactful Component Team in Agile

Component teams are a reality and they do exist for specific purposes. In the programs I worked on, there were some component teams that worked on specific layers of architecture such as mid-tier validations and generating the PDFs with a click to mirror the screens. 

They were formed because the intended solutions at these layers required enormous explorations of different tools, open sources, design approaches, etc before these layers could cater to vertical slicing of the application to produce an increment. So essentially these teams had SME’s, Architects, or senior engineers’ part of it for a focused effort on a layered solution which otherwise was not possible to achieve as part of the feature team who primarily focus on the functional increment.

Posted on

Live From INTERACT: Microsoft’s Developer Velocity Research

This week we have another episode from the 2021 engineering leadership conference INTERACT. In this live conversation I interview Henrik Gütle, GM of Azure for Microsoft Canada.

Henrik joins the podcast to break down the results and key takeaways of Microsoft’s research into the impact of remote work on developer velocity - and what engineering leaders can learn from it.

Posted on

The Power of DevOps Self-Service Platforms: How Standard Tools and Tech Increase Developer Velocity

Introduction

By now, most organizations in the business of delivering software will likely have a DevOps strategy. Even if adoption is only partial, the maturity of DevOps enables firms to improve delivery by implementing the tools and practices across their organization that best suit their needs. 

Once the benefits of DevOps are realized, the business case for scaling DevOps across the enterprise inevitably grows. However, there is a key problem when it comes to scaling DevOps, which is outlined by Gartner’s 2019 prediction that “by 2023, 90% of enterprises will fail to scale DevOps initiatives if shared self-service platform approaches are not adopted.” Providing self-service capabilities allows product development teams to quickly provide new features and push changes to customers while also allowing the self-service platform owners to focus on providing new infrastructure automation capabilities to further support the increased product velocity.

Posted on

5 Characteristics of Modern Enterprise Architect

Enterprise architecture has come a long way in the past decade. With more and more technologies emerging every day, taking advantage of them and creating a better enterprise architecture becomes quite essential. By integrating new technology into the enterprise architectures, we can achieve fruitful results even during difficult times.

This article will give you the 5 characteristics of a modern enterprise architect that everyone should know. Besides that, you can also learn how to build the required characteristics to stay relevant and grow your business.

Posted on

Winning the Customer With Experience Architecture

The airlines, like Delta, have long understood the power of a curated customer experience to assure loyalty.

As the post-digital economy begins to boom and the worlds of business process and technology come together, it’s time to think about how we optimize the whole from a unified, customer-centric perspective. Some organizations have begun to master the idea of experience architecture, whereas others are just beginning.

During my years consulting, I’ve had the opportunity to work with complex system architecture. Such as the APIs and data structures across multiple federal agencies that manage annual earnings and death records for every person in the United States. I’ve also experienced complex business architectures responsible for moving passengers, aircraft, and cargo around the world in a safe and predictable manner.

Posted on

The Case for Software Architecture Makeover

A few years ago, a friend of mine shared with me a white paper that he thought would interest me. This paper described the concept of distributed application architecture through small self-contained application components deployed across a larger corporate network. Eager to impress my friend, I put down the article and exclaimed: “I know where this is going, microservices.” He smiled and replied, “Look at the published date.” To my astonishment, the white paper was published in the late ’90s on the subject of the then relatively new technology called Enterprise Java Beans (EJB).

Sometime later, I hosted a technology leadership forum at a major insurance company in New York. One of the key discussion points included emerging technologies, and of course, microservices. I used the “EJB” anecdote with a profound (sarcastic) conclusion that software architecture styles and patterns do not drastically change, but rather evolve, while software reference application architecture based on a particular technology stack has a lifecycle of emerging, mainstream, and legacy.

Posted on

SAFe and Business Architecture


SAFe and Business Architecture. As organizations begin their Lean and Agile journey with SAFe®, SPCs will introduce a tool designed to help organizations determine the best, most logical place to launch their first Agile Release Train (ART). The Value Stream and ART Identification Workshop is designed to help organizations identify the sweet spot where an opportunity to deliver value intersects with a clear problem to solve, leadership support, a clear product or solution, and collaborating teams.

It’s challenging to meet the criteria mentioned above, which is why many are tempted to launch ARTs within easier-to-identify constructs such as organizational silos. This rarely works. As we know, value often does not follow the organizational hierarchy. However, it’s important to understand that value stream identification is the first step in an ongoing practice of flow management to optimize the speed of delivery, quality, and customer delight.

Posted on

Tips for Architecture Management/How to Work With President Business

Some days I think that life as a software architect runs like the story from the LEGO Movie:

"We have to do the right thing,
unblock creativity,
save the world,
free the master-builders,
prevent the destruction of everything,
beat the bad guy,

but also -- fall in love with the business,
help them to understand why they feel the way they do,
guide them to enlightenment,
so we can all live in peace and prosperity together."

There are so many obstacles to success and a big part of managing your software architecture is getting the business folks on board, getting them to understand what you are saying, why you are saying it, and convincing them that the changes you are proposing are worth the investment. But why? Why is it so difficult to convince them, and why are we not all on the same page to begin with?

I will present one idea about why businesses and architects see the world so differently and, then, I'll give some tips for how to manage your architecture successfully, even given the challenges. I'll show you how to be a master builder and save the world.

Intrinsic and Extrinsic Motivation

As software architects, those of us who aren't lost in our ivory towers, really LOVE our software. It's our baby. We want to look after it, nurture it, tend and care for it, and help it to grow and get better. We understand how it works, what it's good at, and what it's bad at. We long to remove all the cruft to simplify and polish it. We are motivated from within to do the RIGHT THING with our software. Solving difficult technical challenges and building beautiful software is what gets us out of bed in the morning. We are "intrinsically" motivated. We don't need any external impetus to do what we do; we do what we do because we love it.

But, now, let's look at other people in our organizations. Not everyone is motivated from within. Not everyone sees the bigger picture. Some people are motivated by very different things, such as simpler, more superficial things. Some people just want to hit their targets, make the revenue figures, or meet some metric or other. As our careers progress and we rise up within our organization, we tend to find more and more people who are motivated this way. I'm sure they are lovely people, and I don't want to tar them with the "pointy-haired boss" brush but, well, there certainly are some parallels with the famous Dilbert cartoons. Some people, higher up in the organization are not there because they care about the product, or the customer, or this thing or that thing. What gets them going is hitting the mark, pleasing their boss, getting a bonus, or whatever else. These people are motivated by external effects. They are "extrinsically" motivated. If you took away the external factors motivating them, they wouldn't know what to do.

Of course, I'm simplifying a situation that is much more complex in reality. Not everyone is one thing or the other. Not all bosses are extrinsically motivated and not all engineers are intrinsically motivated, but there are some trends there. Perhaps it makes perfect sense for those above to be extrinsically motivated, as they ultimately need to please their shareholders and that means making the numbers.

Some traits and consequences of these types of motivation I've summarized in the table below. (If you'd like to read more about this topic please see the references below).

Posted on

How Scrum Helps Developers Build Technical Skills and Flexible Architecture

Developers who tried to build at least one product for an end-user know how many things are essential in a product: thoughtful UX, friendly UI, good performance and stability, security and data consistency, logging and maintenance, etc.
Multiply this to the number of platforms that you have to support. Add marketings and licensing, client support and bug reports, new feature requests, and competitive product pressure.

It’s hard to track everything in one head, and it is even harder to be perfect at every job. That’s why we work in teams. That’s why we use project management processes.

Posted on

Be An Effective Change Agent – Four Tips From a Software Architect

A primary requirement for a software organization today is to be able to introduce and maintain change at the speed of business. Driving innovation for any organization is no mean feat, but as holders of technical roadmaps, design patterns, and engineering practices, it is central to an architect’s role.

The ability to change software is holistically dependent on the software design as well as the systems, processes, and teams responsible for delivering it.  Architects must consider how to innovate across this landscape. That requires an understanding not only of the technologies and processes that can enable change, but also the complexities of adoption, both from a technical and organizational standpoint. 

Posted on

SOLID code, the Silver Bullet

SOLID is one of those words we developers throw around us, implying some deeper meaning, hopefully helping us to create better software systems. It should be second hand nature to all (OO) developers, but unfortunately is often misunderstood, or used to defend a decision, based upon flawed logic. Hence, in this article, I will try to "dumb it down" and use analogies for each of its 5 items, in an attempt at making it more easily understood, to avoid confusion.

Single Responsibility Principle

The "S" I'm solid implies that each class should only do one thing. It often helps to break down your flow into verbs to make sure you follow this principle. For instance, imagine you have a task scheduler, that should implement the ability to create tasks for execution at some point into the future. Maybe you want it to have the ability to persist tasks, in case the process is recycled, without dropping tasks. Imagine Hangfire here as an example. Well, ask yourself how many verbs you have in the above feature requirement, and then try to group them into related actions. I could find the following.

Posted on

Research Spikes in Agile

In Agile, we have to think about both long-term and short-term goals. The long-term goal is to ensure the customers' needs are translated into release themes. Short-term goals are meant for execution and deliverables. Long-Term thinking translates into release themes, which are split into epics.

A spike in Agile denotes something is not clear to the team. It needs more research to proceed further. In such cases, the recommended approach is to have time-boxed research events called research spikes. Some of the benefits of such an event include: