Being in the design phase of a large-scale project for the State of Ohio, I have been giving a lot of thought to the problems of Modeling and Design.
You see, I am in an interesting position on most projects – I am an actual Solutions Architect. In today’s IT environment the term ‘architect’ has grown to mean “good coder with big mouth” and I don’t really fit that mode. I am not the best coder in the room most of the time – although the size of my mouth could be debated.
What I excel at is the designing of solutions, which leads me to use the term ‘software designer’ to describe myself. This isn’t terribly good either, as it leads people to believe that I produce pretty graphic design and UX, which isn’t my specialty either.
What I am, in truth, is a Software Modeler. I am the person that figures out what the domain model looks like based on the requirements of the system and the realities of the project. The one who stands at the end of the room and scribbles boxes on the whiteboard? Yeah, that’s me.
Thinking about this has really helped me to hone down the definition of SQL Modeling in my head. People ask me “Why is Oslo hooked to SQL Server? Is it just another data language? Don’t we have enough of these? I thought M was a language not a database thingie! Oh woe is me!” Well, the key is in the difference between design and modeling, and how tightly coupled the model and the database really are.
Software modeling begins and ends with data. The user interface is, I hate to point out, now the purview of the business analyst. When I get a functional specification for a project, it has the UI in it right there. I don’t have to ‘design’ that any more. All I have to figure out is how to do it. This effort is modeling, and it is about data.
Today I needed to estimate an inventory system with a few quirks. Without thinking, I got out my notepad, sketched an ER diagram, and worked from that. How many POCOs? How many adapters? How big is the entity model? Yes, eventually I had to estimate how long it would take me to build the screens, but the bulk of the work was in the domain model, where the work is done, as it should be.
Imagine if I could have instead described my model in text, without all of the brittleness that the ER diagram entails, and have that text description emit both the databases and the POCOs for me? And then, if something changes, I could change my scratch model and my other code changes? What if it didn’t break my changes or additions? What if it didn’t create scores of stored procedures that are impossible to manage?
Wouldn’t that be nice.
This, though, is the goal of SQL Modeling. It is clear as day exactly where it fits in the product lifecycle – right there overtop of my fancy notebook scrawls. Those boxes and chicken feet have a place somewhere, but it’s time for a modeling solution that actually is a solution.