Engineer. Architect. Designer. Modeler. Analyst. Tester. Mentor. Trainer. Speaker. Writer. My professional career has been in many different roles with diverse technology stacks in many business domains....and even after a long career, I still look for new challenges that stretch my abilities in new directions. After many years as a tech leaders, I returned to my roots as an individual contributor and love it!
Speaking at conferences allows me to share my experiences, insights, and expertise with you and hopefully gives you the context and background to help you navigate the constantly-changing technical landscape we work in: while the solutions may be implemented differently now, the problems are often age-old and recurring. My goal is to help you recognize and understand that, in whatever problems presented to you.
Mature organizations often have that all-encompassing, business-critical application that represents person-decades of effort. It likely started as a very well-defined, well-implemented solution to original business requirements, but over time became a behemoth as functionality was added without considering the overall impact.
Unsurprisingly, the application has not aged well and eventually leadership admits there are problems:
* consistently increasing production bugs that require immediate attention;
* dramatic increase in time required to deliver new features;
reliance on key individuals to do critical work due to cognitive complexity;
* inability to successfully monitor application to understand its true state.
Legitimately, organizations are loathe to accept that a rewrite is required; it's often interpreted as engineers wanting to do engineering for engineering's sake. Leadership makes a call to action to find a less-costly and more timely solution. After much analysis, discussion, deliberations and hand-wringing, it's decided: Demonolith the Monolith!
Really, data modeling? Is that even a thing any more?
The days of formal data modeling are definitely years in the rearview mirror, empowered teams define their data as they see fit, implement, and move on. Done. And we'll deal with short-comings down the road when they arise, that's Agile, let's keep moving forward (to data architects' frustration when trying to make sense of it all after the fact).
But "modeling data" extends beyond what is persisted in a database server: API Payloads, messages, configuration files, document metadata, Redis indexes are forms of data we define and work with regularly.
If I've got your attention, join me to discuss data modeling, this time from a software engineering perspective!
Searching for speaker images...