Domain Driven Design is getting a lot of attention in the architecture space, and why shouldn’t it? Making the focus of design on the business problem makes sense! Traditionally, we’ve had small groups of senior developers meet with an analyst, try to understand what the business problems are, and then dive deep into the technology to try to solve that problem. Unfortunately, some of the main outcomes are that the problem solved isn’t the one that’s needed to be solved, or it’s overly focused on the technology and the implementation of an idealist architecture that isn’t flexible enough to solve the problem. In both cases, the problems aren’t well resolved.
Enter Domain Driven Design (DDD), where the idea is to focus more strongly on the business, business process, and business problems. Some might argue that the architecture should be subordinate to those things. But, even with this newfound focus on the business, it’s been found that a lot of the problems are still overly focused on the technology at hand (if all I have is a hammer, everything’s a nail). Enter Brandolini’s Event Storming technique.
The Event Storming method is focused on first identifying the business process, and then building the architecture around that. The process is always at the center of the world in event storming, and everything hangs off that. Your business process becomes the bounded context. This is yet another reason that understanding the overall, cross-silo, business process is imperative. (for more on why you should care about Business Process Management, see this article) Once you understand the business process, you can start asking why things happen, how you know they happened, how you can test it, what happens if it doesn’t (again, good things to know in a BPM context too). These are your events. Hang these on the process model you’ve already put on the wall, make them part of the visual map.
If you read Brandolini’s work on Event Storming and how it’s morphed over the years, you’ll see that it’s begun to blend the ideas of multiple tools into one. You get user personas like in story-boarding, early identification of key tests from test-driven development, and all of this from a facilitated session similar to process discovery.
All of these ideas are important when building new software, not because they help create better code, but they do an excellent job of providing information for the team. It gives the entire team the context they need to effectively design and build a solution that will solve the business problems at hand. But, all of it needs to start with understanding how the business works.
When the product you are working on is aligned with the strategic direction of your company, and everyone can see the work as it’s being done, magic happens. The politics, the fits and starts, the constant rework, the change in priority. It all melts away. In this lunch and learn, we'll share with you a simple approach to product management that includes creating a product vision to create alignment, and a product road-mapping process that ensures transparency to help the overall organization focus on results.
Complimentary lunch will be provided.
Tue, Aug 28 11:30 AM – 1:00 PM St. Louis, MO
Seating is limited so reserve your spot early!
Nikky Oberdas has been working in technology playing multiple roles for 20 years. She's a ...Facilitator... Trainer... Mentor... Writer... Focused on leadership alignment and product strategy. She loves to help teams and organizations find their truth, say their truth, and get unstuck - to unleash creativity and the art that is creating great software. Bring your humanness to work!
The cloud seems to be all anyone talks about these days; and based off of the reported earnings from the major cloud vendors, it seems like organizations are beginning to move their workloads into the cloud at a faster rate than ever. But for as many organizations making the move, there are just as many who still want to know what it means to “go to the cloud”. The common misconception is that moving to the cloud simply means lifting and shifting your infrastructure into a cloud environment. While this could have some potential benefits, moving to the cloud is about much more than that. Moving to the cloud is a about enablement.
Do you have metrics on how much time your teams are spending to keeping the lights on? If not, could you guess? Some teams are averaging a staggering 28% of their time focusing on things like operational overhead, deployments, maintenance, and a mix of other administrative tasks. To put that into context for teams that run two-week sprints, that’s 2.8 days per sprint that are not going towards adding new business value. The cloud eliminates the pain of purchasing and installing hardware, planning for hardware capacity, installing operating systems, and of course ongoing hardware maintenance. And that’s just for infrastructure as a service (IaaS) adopters. For those looking to use platform as a service (PaaS), then you can also save yourself some time with operating system updates, system hardening, and even scaling to some extent.
I have been a part of many projects where developers start coding, get some features ready for testing, but have nowhere to deploy; or if there is a destination for their code, it’s usually significantly underpowered and painful for others to use. This is typically because new hardware needs to be purchased to support these new applications, or the hardware available is well over capacity. This has had significant impact on the project schedules and has even resulted in halting a project I’ve been on. Organizations that have cloud subscriptions are able to spin up new environments in minutes. And if the new project doesn’t work out, the environment can always be taken down. The cloud provides a low-cost, low-risk, and low-latency option to start up and deploy projects more quickly.
Do you remember the last time you walked into a store to rent a movie? Or buy a CD? We can now stream just about any movie or song, on any device, at any time of day. Netflix and Spotify have completely disrupted the industries they serve. As an organization, would you be able to react quickly enough if a startup began disrupting the industry you serve? Would you have the agility to survive? The cloud provides an environment where organizations can quickly pivot if necessary. Most cloud vendors also provide competitive advantages in the way of artificial intelligence and machine learning at commodity prices. And if you’re application is successful enough, then cloud infrastructure can provide massive scale and global reach that’s not even possible private data centers.
This is not meant to be a comprehensive list. Many cloud strategies have plans to enable one or more of these as well as others that aren’t on this list at all. The point to take away is that many view “moving to the cloud” as an IT or technical decision. While IT should undoubtedly have a stake in the cloud strategy, a move to the cloud isn’t really a technical decision, it’s a tactical one.
In talking with people that are new to the idea of iterative and incremental development, this is often the most common thing I hear.
"We can't deploy anything until we have everything done"
Of course, this raises the stakes, because you don't get an opportunity to learn about what your customers want. You can easily gold-plate something that doesn't fit the need in the market, ending up months or possibly even years behind your competition. Even in a regulatory environment where you feel everything is spelled out for you, there's often quite a bit of room to be innovative or deliver incrementally.
There seems to be this belief that people don't want products unless they have all of the possible bells and whistles, especially in an established market or product. But I think there's an amazing case study to evaluate the veracity of this claim, and it's hiding in plain sight.
Tesla has been developing the Model 3 software in a very iterative and incremental way since they rolled it out. The first group of cars delivered to their owners didn't even have FM radio enabled! If you wanted to listen to music in your shiny new $50K+ car, you had to do it through your phone's Bluetooth connection. The next thing was that didn't exist was an intermittent wiper setting, you could only use the auto wiper feature, low, medium, or high. In true learning organization fashion, they received a tweet from a customer informing them that when they open the door in the rain, the wipers kicked on, soaking them, and the door of the car. The next software update addressed that problem. They've even made it incredibly simple for you to provide feedback, no going to the website, sending an email, or anything that droll; simply say, 'bug report' and articulate the nature of the problem, and it's logged. Simple, easy, real-time. The car has been steadily improving since the day it rolled off the assembly line, and guess what? People love it.
People are in love with the idea that the product they paid for is continuing to get better and better. And Tesla has shown with the Model S and X that they will continue to update the platform as they think up more things that the cars can or should do. It's no wonder that Tesla is valued so highly, they're doing something that no other automaker is capable of doing right now, and that's making the product you buy, get better over time, instead of being stagnant.
I think that Tesla has demonstrated, in an existing, highly competitive, and regulated market, they're able to innovate and deliver in an iterative and incremental fashion. The question you have to start asking yourself when you say it can't be done for you, "What's keeping me from doing that?" and then take a very hard look at the answer. Are those reasons really real? Have you tested them to see if they're actually valid? What's the actual likelihood that any of them will come to bear? If they're not real, then try it out! Figure out what the minimum work you have to do is, then give it to your customers and see how they are using it, learn from that, then build the next version to improve it.
One thing that we learned from Google’s Project Aristotle is that the highest performing teams have a single thing in common. What is that thing, you ask? Safety. Not safety as in they are in physical danger, but a far more difficult to measure safety, psychological safety. This is the safety to speak up without fear of retaliation, the knowledge that we can disagree and it’ll be ok, that the truth is not just welcome, but expected.
When joining a new team, creating safety is imperative to ensuring a great working environment, but how do you do that with a bunch of strangers you’ve never worked with? How do you create an environment where you know how to argue effectively with each other? And most importantly, how do you create a space where you aren’t just the other resources on the team, but you’re a human being with aspirations, goals, desires, hurts, and all that goes with it?
The quickest way to create that connection, is to help people understand who you are, and you to understand who they are. Where did they come from? What are they proud of? What are they not so proud of? What made them happy? Are they happy now? This is all incredibly valuable information that helps you create a bond that’ll allow constructive disagreement. To get to this, there’s an incredibly powerful tool, Journey Mapping (it may have also been called empathy mapping).
The idea is this, draw a graph with the x-axis being time and the y-axis being happiness. Draw a line across indicating that it’s not happy, not sad, more like, ‘meh’. Now each person independently starts at whatever point they choose, it could be early childhood, it could be their first job. It’s up to the facilitator to set the rules, but the more open you are here, the better everyone will know you. From here, you put a dot on the graph for each event that you can think of, be it happy or sad. Once you’ve caught up with today, connect the dots, and add any kind of embellishment you choose, draw pictures, make frowny faces for the unhappy incidents, get creative! This is your opportunity to show your personality, so go bananas!
After the drawing period is over, each team member takes the whole team through their graph, telling them about why there’s that three your trough after your second job, and why you left the job that had you at the peak of happiness. How did you arrive here, at this very moment, in this room, at this company? The team can ask questions as they learn about you, and before you know it, you’ll find lots of laughter in the room. This is the first step in creating team safety.
With this grounding in a shared understanding of where you come from, the team will more quickly start to gel and work together more easily. It’ll open up the team, accelerating the transition through the Tuckman stages from forming through storming and into norming.
Try it out with your team and let me know how it goes!
Page 1 of 11