Archive

Posts Tagged ‘architecture’

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.

Advertisements

Programming in Grades

(this post is a work in progress, but I’m sharing it now to think about the grading more)

As an architect and a developer I have often been frustrated by the gap in understanding between what I call “rock star” programmers and “average joe” developers. To start, let’s define who’s who:

Rock Star Developer
The rock star developer is the guy that eats code in all forms at any level of complexity. He can read it, decompile it, reconstruct it, and communicate it to others. What he may not be able to do is understand the big picture and how code relates to a business. If he does, then he’s a developer God and there are an infinitely small number of those people.

Average Joe Developer
The average joe developer is the guy that writes code for a living, but would very likely rather be doing something else. He has a life that doesn’t include much time on the computer beyond his work day. He’s not going to seek new knowledge. He only grows when internal systems and standards change and he’s forced to learn new things, which he will do happily, but not ambitously.

Having been in this business for 25 years (many as a consultant), I have witnessed many IT environments. It’s my belief that the number of Rock Star developers is a relatively small one. By far, the vast majority of developers are Average Joe’s.

This presents a very serious problem in most IT departments in that the minority is in control of the standards and architecture for the majority. I can’t tell you how many times I’ve witnessed the development of a “framework” that is great on paper, sells well to the business, but no one ever asks the Average Joe’s what they think. Everyone just expects that they will learn it and move on.

The problem is that this will stress out most Average Joe’s and they will become less productive. If they can’t grasp the new “framework”, they’re likely to take months if not an entire year to learn the environment.

So then you’ll hear the rock star’s say, “This isn’t that hard. All good developers should know this stuff.” and will convince management to hire consultants or more senior developers. This creates an imbalance where too many cooks are in the kitchen and egos will start to come into play. IT departments are no different than a carefully developed fish tank and its ecosystem. If you have too many rock starts, things will get unmanagable. If you don’t have any, standards will be tossed aside and you’ll have as many styles as you do programmers.

So there are a couple of problems here. One is to balance out the number of rock star developers with average joe developers. The other is, how do you determine who’s a rock star and who isn’t. So I’ve come up with a grading system to define what I think they are and you can chime in with your thoughts. We’re going to categorize various development tasks with a grade level (as in 1st grade, 12th grade, associates degree, bachelor’s degree, masters, doctorate. We’ll keep the basics at 4th grade. These are the most basic tasks a programmer needs to be productive. The scope of this grading system is strictly business application development. There are other areas of development, such as programming computer chips, that are so different that they need their own grading system. This also ignores communication skills like speaking/writing English.

4th Grade Developer Tasks

  • G4-01: Ability to use a Windows, Linux, or Apple OS X computer, including log in, run programs, use a command line, print documents, e-mail, instant message, and use a text editor.
  • G4-02:Ability to use the file system to locate, list, and manage files.
  • G4-03:Ability to write a Hello, World! program in at least one programming language without a book.

6th Grade Development Tasks

  • G6-01: Ability to use a platform specific Integrated Development Environment such as Visual Studio or Eclipse.
  • G6-02: Ability to create a basic web page with a form that posts data to a server.
  • G6-03: Ability to handle server side logic of a given web page in at least one programming langauge.
  • G6-04: Ability to handle querystrings and form variables.
  • G6-05: Ability to access a database using at least one programming language.
  • G6-06: Ability to use data from a database to output to a web page.
  • G6-07: Ability to write simple CRUD SQL statements.

8th Grade Development Tasks

  • G8-01: Ability to create a class with private and public members.
  • G8-02: Ability to create SQL Statements with one JOIN.
  • G8-03: Ability to create Stored Procedures and Views.
  • G8-04: Ability to write a Functional Requirements document.

10th Grade Development Tasks

  • G10-01: Ability to create protected and static members on a class.
  • G10-02: Ability to create an abstract or base class with virtual members.
  • G10-03: Ability to create a sub class with overriding members.
  • G10-04: Ability to develop a complete CRUD application in at least one programming language, including the data model, the object model, a data access layer, screens, web pages, with validation, exception handling, logging,
  • G10-05: Ability to create SQL statements with multiple JOIN’s.
  • G10-06: Ability to create database Functions, Indexes, and constraints.
  • G10-07: Ability to develop a simple data access layer.
  • G10-08: Ability to designa a simple domain model.
  • G10-09: Ability to design a simple data model.
  • G10-10: Ability to write a Detail Design Document.
  • G10-11: Ability to write a unit test class.

12th Grade Development Tasks

  • G12-01: Ability to develop polymorphic class structures.
  • G12-02: Ability to develop custom generic types.
  • G12-03: Ability to diagnose database performance issues.
  • G12-04: Ability to design a complex domain model.
  • G12-05: Ability to design a complex data model.
  • G12-06: Ability to develop by writing unit tests first.

BS Level Development Tasks

  • GBS-01: Ability to create and use complex data structures.
  • GBS-02: Understand and use big O notation.

Masters Level Development Tasks

  • GM-01: Ability to develop a compiler for an existing programming language.
  • GM-02: Ability to develop a compiler for a new programming language.

PHD Level Development Tasks