That’s the good thing about being passionate about something, you see the long game. You see what something will become tomorrow; not what it is today. You need that patience and vision when doing a teardown. So, what’s the purpose of a teardown? For software, it’s about reverse engineering the product, identifying its component parts & functions, how they all fit together, and then putting it back together. For a car, it’s about replacing old with new. All the way, down to the nuts & bolts, seats, and door panels. Here is a picture of the car in its current state. How did it get there? Well, read on.
Lots of stuff here has been ‘torn down/torn out’. However, before the teardown could truly begin for this beauty, it needed some basic components (mostly the steering and suspension) renewed by someone specialized in retro cars. To do this I had to part with the car for almost 2 weeks as it sat in the shop and waited for the appropriate parts to arrive. In the meantime, I realized the other thing that is needed to start the hardware teardown process is a home. After the shop finished with the `69, it has fit in nicely into the middle of my garage dispelling all other non-car related objects to a distant corner. As of today the entire interior of the car has been extracted, different components of the engine have been removed to be cleaned/ replaced, and Marc and his friend Pat (aka my hardware re-building team) have begun the next step; a very large and potentially expensive to-do list. As with any project of this magnitude there were some interesting/sketchy findings/obstacles getting the car to this point, the steering and suspension the least of these obstacles. But where does one go from here? Now that everything is torn out what can go back? What needs to be replaced? What needs to be fixed? And heaven forbid what needs to be scrapped? So many questions, so many heated discussions (arguments) between team members and currently so few answers. Oh the beauties of a teardown! On a different note, don’t you just love that wooden steering wheel? But like the rest of the car I have a vision for it.
Now on to the teardown of PIAB. Where to start? Well, it’s a web application that is built on the PPDM 3.8 data model. That seems like a good place to start, the data model. So, PPDM. I think I know a thing or two about it. The issue is now how does it get implemented? What pattern does it follow? Guidelines? Inter-operability? Architectural Principles? No better way to gain the knowledge than to jump right in. But first, a little thought about what I was looking for and what to do with it when I find it. I came up with a simple idea: I would build the database according to the documentation. Seems simple, right? And it should be, but writing documentation is a tough thing to do; Esp. when you have an old guy like me that might be somewhat set in my ways on how I like things and how I expect it to run. Well dear readers, I can tell you that I was pretty pleased with what I found. As always, there are a couple of ways of looking at things. You can see the forest or you can see the trees. By this I mean, do the individual files work, are they called in the right order (remember that the PPDM data model has full referential integrity designed into it & I hate turning R.I. off) and does the whole install strategy lend itself to repeatability? Will upgrades be easy? What about integration with other PPDM based applications? That’s an important feature, IMHO. With any implementation of the PPDM data model, it’s my belief that the overriding goal should be the ability to mix and match multiple applications from multiple vendors with the possibility of multiple data sets thrown into the mix. All of this integration can be tricky, but that’s the purpose of the meta model module within PPDM. Using it to capture the structure of the data model (which is supplied by PPDM as part of the standard install) but it can be used for more. It can capture content of your database as well as context. And that definitely will be another blog post.