How Can I Help?

As I get closer to ramping up my job search, I've been thinking about how best I can serve my future employer and what I need from them, so we're aligned.

My background is important. I started writing code in the late 70's in high school, eventually taking programming roles from 1985 through about 2017. These projects include DEC BASIC and C, PC BASIC, Visual Basic, relational databases, ORMs, my own frameworks, continuous delivery tools, then C# and .NET framework. I followed a fairly standard path onto the Internet with ASP and ASP.NET and MVC, MVP patterns. I learned how to build contracts and services, which turned into web services. Eventually I found MongoDB and DynamoDB and AWS and Azure.

It was 2015 when I started leveraging Domain-Driven Design and that started the unraveling of my architectural mindset. I was a very traditional relational-centric, data modeling first architect. I was very successful doing things this way.

I wore the hat of application architect, senior developer, tech lead, data architect, and reporting architect on a highly visible project at Accenture to write a new application to track and manage performance. Accenture was notorious for stack ranking every August at the end of their fiscal year. Performance Achievement replaced that process in 2016. We used AWS DynamoDB, virtual machines with ASP.NET web services, and Domain-Driven Design to model the business as we released daily changes for the first year.

This project was a massive leap in productivity and a revelation to me and to others within Accenture. There's a public case study.

One of the primary productivity increases came from abandoning data modeling as a starting point and any use of a relational database. I'm sure everyone knows how challenging it is to manage schema versioning and change in a new or existing application, especially if the database is shared among many applications.

There were productivity gains from using a relational database, but once you start modeling your business by bounded context, you start to see how each context should own its own data and then you make the leap to storing that data in the best technology for a given context. In other words, you let the business model drive the architecture and the technology, not the other way around.

But once you do all of that, you have another revelation. Schema based data is better suited to business intelligence and analytics, not operational data. Then it becomes a practical change in enterprise architecture to build bounded contexts with microservices and their own operational data stores and publish change events that seed your business intelligence data warehouse.

Of course, this kind of architecture is meant for complex multi-application environments, not for smaller, simpler applications.

This brings things back around to how I can best help my next employer.

You probably have legacy systems that you intend to modernize. You might even have started to migrate to the cloud or have done a lift and shift to the cloud. You've delayed modernization though because the level of complexity prevents any easy fixes. I won't presume you don't already have a strong team.

But if you are in this position, I absolutely can help and can wear many hats to integrate with your personnel and build a clear path from today to tomorrow. But you tell me, knowing my background, how can I help?