Archive for the ‘architecture’ Category

Designing Applications in a Vacuum (don’t do it)

Throughout my career as a software engineer/consultant, I’ve run across many passionate arguments for software development methodologies. I can’t count the times I’ve been in a room with very loud discussions about placing business logic in code or in stored procedures. I think it’s safe to say that the coders won this argument and I don’t hear these discussions anymore.

There have been others….Java vs. .NET, Fat Client vs. Web, SQL Server vs. MySQL, OO vs. Procedural and so on.

There is one I’ve hear recently that’s relatively old (10 years) that has some traction, but I don’t think it’s by any means a standard. This is Eric Evans’ Domain Driven Design philosophy (there’s a book on it). Admittedly, I’ve built many systems starting from the data model and more recently looked at API First. I’ve often developer object models and domain models as a part of my process, but I never really focused on that aspect as a required first step.

With the prevalence of web applications and specifically REST, Web API, and AJAX oriented implementations, I think I’ve come to a working conclusion. None of these are starting points (API, Domain, Data). They are deliverables.

You may work between each of these deliverables as you design an application, but you will learn something different and come up with different questions when you touch each area of design.

When you touch the domain, you’ll be asking resource and behavior questions. When you touch the API, you’ll be asking extensibility and shared service questions. When you touch the data model, you’ll be asking questions about reporting, atomic transactions, and performance.

These are all very important questions and by starting at a single point, you could potentially ignore important questions and thus, important design decisions.


Corporate Technical Architecture and the Missing Link

I’ve had an obsession with technical architecture from the moment I started typing on a computer terminal back in the late 70’s. Over the course of my 27 year professional career I’ve had many opportunities to be involved in architectural discussions. In recent years I have led these discussions or been a part of the leadership.

I shouldn’t say discussion because my viewpoint almost always garners derision and fuels heated battles over the makeup and purpose of a new technical architecture. I’ve thought long and hard about the things I value in a new architecture over what other (most) architects value. I’ve struggled to articulate my vision and because I’m not as strong technically as others, I generally lose battles quickly and badly.

But I do know what I’m talking about and the other architects keep proving me right. Here’s why…

Almost every architecture team focuses on technical vision and business requirements. So if a company needs to be able to share services across a number of silo’d departments or divisions, this will require a certain type of disconnected and service-oriented architecture. At a high level, this is good and right. But everything goes haywire in the implementation because these same technologists decide to find the most technically elegant solution available.

What most architects fail to take into consideration, or simply deride any attempt to “dumb-down” their goals, is that the results of their work have an associated future-cost and could potentially damage the business. This future-cost/business risk is defined by the level of talent required to implement and maintain the proposed architecture.

The missing piece is the HR department and the market for available technical talent. When implementing a new technical architecture, the architecture team should be forced to sit down with HR personnel and look at current and projected levels of talent in the marketplace and their associated costs. If a proposed implementation requires senior level talent, then HR should be able to offer insight into current and future costs associated with that proposed implementation from a building and maintenance perspective.

“This year, the proposed implementation will cost the company $2,000,000. Maintenance costs will increase to $4,000,000 because the level of talent required to maintain the proposed architecture will likely come from the contractor world and not from full-time employees. We propose you lower the complexity of the implementation so that a mid-level developer can maintain the system. This will open availability and lower future costs to $2,500.000.”

This is the sort of conversation that is missing from every architecture discussion and needs to change. I’ve sort of realized that if I were to carve out a position in a firm, this is where I would excel. I would be able to work between HR and the technical team to monitor proposed implementations and their future costs and complexity.

It’s about time this position become standard in all mid to large corporations.