Blockchain is getting a tremendous amount of buzz lately. Some say it’s the biggest technology bubble since the internet. But when you dig deeper with most pundits, they are hard pressed to explain exactly what it is and how it’s going to change the world.
Join us in this no-nonsense, straight to the point discussion about what blockchain really is, how it works, the use cases for solving real world problems, and its implications to cloud computing and technology strategy at large.
Complimentary lunch will be provided to registered attendees.
Wed, Dec 12 11:30 AM - 1:00 PM St. Louis, MO
Application Modernization is a term that I’m almost positive you have heard of by now. Generally it is considered to be part of the broader definition of Digital Transformation. On it’s surface, App Modernization is simple. You have aging, legacy software, you need to update it. In practice, it’s much less simple. There are a myriad of things you need to take into consideration for a successful foray into App Modernization. I’ve put together a list of things that, I feel, are necessary things to do before and during any App Modernization project. This isn’t meant to be an end all, be all, but should give any one who is thinking about App Modernization a baseline to start thinking about what’s involved.
“It’s Not Broken, Why Would I Fix It?”
I’ve had this conversation more times than I can count. It generally revolves around the fact that a 20 year old software product has been running just fine pretty much forever. How could I possibly suggest that the they throw away money ‘fixing it’. This response is usually the start of a great conversation. While I am a huge proponent of taking a pragmatic approach to anything I do, I think it’s important for organizations to take the time to think about these things seriously.
Start weighing the application’s importance to the business against the risks that the technology will not be supported forever. Add to that the fact that finding people to work in aging technologies can be very difficult, and prohibitively expensive. The cost of Modernization is suddenly far less than the cost of the supporting the application over time.
Rome wasn’t built in a day. Likewise, your software portfolio took a significant amount of time and planning to build up to the point where it is today. I would recommend not attempting to modernize your entire organization’s portfolio all at once. The task would be overwhelming for one, more importantly mistakes will be made when modernizing. Inevitably, you will try some things that make sense up front only to realize that they didn’t work out. That’s fine, good even. We’re humans, we make mistakes, we learn, we iterate. If we’re touching our entire code base all at once, those iterations are more costly and frustrating.
One approach to App Modernization is called Rip N’ Replace. Basically, it just means to rewrite, verbatim, an existing application on a new platform and/or using new technologies. There are times when this approach makes sense. There’s a tendency for organizations to start here, but I generally don’t.
One of my personal axioms is to always be able to answer the Why question in everything I’m doing. Everything we do as software developers needs to have a purpose. It’s this line of thinking that naturally leads me down the path of needing to define what value the application provides to the business.
Many times, we’re talking about software that was written 10-20 years ago. I find it hard to believe that there haven’t been significant changes to the business, either in operation or in the market, in that time. Now is the time to modernize not just the technologies this application uses, but modernize how this application serves the business today and for the near future.
I touched on the idea of Rip N’ Replace in the previous topic. There are actually 4 approaches to modernization. Modernizing any application should result in two things. Stability for the future and cost savings of utilization of new technologies and platforms. With this in mind, know that each of these approaches present a set of value propositions. Generally, the more you invest today, the more you’ll reap in benefits in the future. Think about these approaches and select the one the makes the most sense based on:
The technical side of software development is just one piece of the puzzle. The trends in software development over the last 5 or so years has shifted to talk about software as a gathering of tools, technology, people, and process. App Modernization should certainly include modernization of the software development process and the DevOps stories. Implementing Agile and CI/CD goes hand in hand with building modern software. Use this time to level up all of these capabilities.
Tesla has recently been in the news because they have, after years of set backs, managed to bring their production of the Model 3 to 5,000 units per week. This is a great milestone for them, and reason to throw a huge party in celebration. However, it’s not all smiles over at Tesla. Turns out, making that many cars means you have to deliver that many cars. This is a cascading challenge.
As we improve aspects of our software development practices, we create bottlenecks that weren’t there before. For instance, developing features more quickly often puts unmanageable pressure on QA. Developing features more rapidly without upgrading the DevOps story that accelerates the releasing of those features means that valuable software (business value) sits “on a shelf” gathering dust rather than being recognized by the end users.
With some intentional and thoughtful planning, and the support of an experienced partner, these challenges can be accounted for and avoided entirely.
Rapidly evolving web technologies, expanding cloud solutions,service offerings, and adopting agile delivery practices – these are all things that can be new to companies as they begin modernizing. An experienced partner will have valuable experience in all of these areas, will be able to help your team to avoid the gotchas, and will point the project in the right direction from the start.
I can provide ideas of how to partner up, if you have questions about how to get started on your own App Modernization journey. Reach out to me on twitter @devgush or at Kevin.Fitzpatrick@PolarisSolutions.com.
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.
Page 1 of 11