Four Architectural Tenets

Similar to other IT functions, it can often be difficult to understand the value of IT architecture and to make the case for strong architectural practice.  When you add solutions as an additional layer of abstraction, this is even more difficult.  In one sense, you are getting further away from technology and therefore more theoretical.

However, in the case of solutions orientation, this added abstraction is done for a very pragmatic reason.  Solutions based engineering allows us to be closer to our end customer.  This is true whether you work in an IT organization or within a product group at a software company.  Our solutions orientation should make it simpler to show the business case for architecture, rather than harder.  Unfortunately, this is not true for many traditional Enterprise Architecture disciplines.  This is not to say that these disciplines have no value.  Not at all.  However, they are abstractions intended to help the technical team order complexity in a way that allows them to design a very complex system.  To the end user or customer, these complex systems are only of a passing interest.  Thus, like a hammer or a nail gun, they should be used only when necessary.  If the architecture framework is making your life as an architect better and allowing you to deliver solutions more quickly, then they’re good.  If they’re slowing you down, they’re bad.

If we are to claim that architecture has value, we need to establish the core tenets of what a "good" architecture is.  This is something that not all architects take into consideration when building projects or systems.  For example, speed of execution is just one benefit of the core architecture tenet I call Simplicity.  There are tons of different ways of expressing core tenets, but to me they all boil down to four basic tenets:

 

I like to express this as a Venn diagram because I feel that when I design something, there is a huge attack surface of any project.  However, the best design is a relatively small point where the Venn diagram overlaps.  Sometimes, it feels like the circles are the size of football fields and the overlap is the size of a postage stamp.  Being the eternal optimist, I insist that there must be an overlap someplace and that I just need to find it.

Core Architecture Tenets

 

·         Simplicity.  Simplicity of design is something than transcends IT.  By definition, the simplest solution that meets all the design criteria is the best design.  Complexity is the enemy.  This is true for many reasons (speed, maintenance, esthetics, etc.)

·         Alignment.   However, the solution needs to be aligned to the requirements of the business.  If the technical solution does not solve the stated problem, what’s the point?  You need to hit your requirements or the design is fundamentally flawed.

·         Quality.  Something that is done poorly is best not done at all.  It’s always easier to do something poorly.  However, I don’t think any of us actually aspire to produce poor results.  This is true for architecture just as it’s true for development or deployments.

·         Future Ready.  One thing we can be certain of in our business is change.  Whatever we build will need to be modified going forward.  Unlike things like cars, our designs will most likely be upgraded several times over their lifetimes.  Good architectures take this into account and allow for future changes.

The Death of Loyalty

In modern American business, the idea of loyalty is pretty much dead.

In years past, there was a sense that employees owed a certain amount of loyalty to the firm and in turn they expected this loyalty to be rewarded by security, advancement and compensation.  Companies would invest in their people through training and development activities that made those employees more valuable in the long term.

This virtuous cycle seems to be pretty much dead today.

In today's reality, certainly in the quickly changing high tech sector where I live, there is very little expectation that the company will "take care of you."  Yes, the probably will provide training but usually that training is focused on short term goals.  There are very few companies in Silicon Valley today who make a sincere effort to develop their technical people and actively manage their careers.

I started my career in an "Old Fashioned" company that had all the traditional trappings of employee development.  Because of this, I benefited in the type of developmental planning and support so crucial to help junior technical people enter the workforce.  Later in my career I actually ran a large professional developmental program designed to create Architects from engineers.

Today, as I look around and consult with my peers, these programs are markedly absent.  I am aware of no major Silicon Valley companies actively developing Architects within their organizations. 

BTW, I would love to be wrong here.  Please let me know in the comments if you're aware of any company doing this kind of work.

So, if this type of development isn't being done by our employers, how are we going to develop ourselves and the next generation of architects?

I've come to the realization that we must do this ourselves.  It is only through community that we can address this problem.  This is one reason why I decided to start writing books.  Not that I think my books will move an industry but rather that I need to share my experiences and learning's.  If one person is helped by this then I feel the effort of putting ideas down on paper was useful.

I have also recently been trolling the Linkedin universe to see if this is a good place for this type of professional development.  As of what I see today, the signal to noise ratio is just too high there to be useful.  Linkedin, as a platform, is awesome for keeping tabs on what everyone is doing and I love it for that purpose.  However, as a learning tool, it's too uncontrolled and too open to be useful.  What's needed here is curation.  A hiking trail that says "start here and end there."

Again, to my knowledge such a thing does not exist.  I definitely welcome postings in the comments section telling me how incredibly wrong I am!

In the meantime, I strongly encourage you to think about how you are helping the Architects in your organization develop.  Mentoring and OJT are our only options right now and that requires effort for those of us already in the profession.