I’ve been in various IT roles and IT departments over the years. The thing I’ve found is actually very interesting – but is wholly opinion. I would however love to see someone study this and see if in fact it is real.
IT teams that have solid relationships between managers and people actually doing the work seem to have a much higher success rate on projects. I am not talking about the always risk “friendship” dynamic. I am talking about open and honest relationships between everyone on the team.
On those teams it seems to me that problems get addressed much faster than they do with IT orgs that have a typical management structures. Again, staying away from the concept of friends, rather it is a cordial open environment.
It seems to me that these teams also know how their organizations make money and are much tighter aligned with the business and business components. IT making decisions on taking projects that directly impact the business.
Anyway – it is something I have observed. Not sure that it is real but it is something that I have seen a few times.
I’ve built things over the years as a software architect. When I think about the failure of some of those projects, later it bothers me. Why is it that when we build something we attach a sense of personal value to that solution. We want that solution to continue until we are gone and sometimes even beyond.
The right thing to do is to always let go of what was, and build what should be.
But can we do the right thing as software architects?
Can we let go of what worked before in order to replace it with a new widget? Are we willing and able to make that leap of faith?
Can we accept change as software architects?
Recently I’ve seen a series of posts between some deep technical and some broad technical architects. It even included the disparaging of a person I find beyond reproach personally.
It was an interesting discussion.
Prior to that I spent another month living in the world of Business Architects, yay or nay.
Part of me says all of this is because we are becoming a profession. It is important (definition wise) when you become a profession to have the lines and boundaries of your profession clearly defined.
But there are other things going on here. I find it interesting that people are hung up on the concept of technical skills. What are technical skills? For that matter when you think about an architect and we think within the boundaries of skills themselves what are we really looking for?
- Organizational Dynamics
To me those are the core architect skills. The others skills around technology are lesser skills – why? Because frankly they are easier to teach someone. I have a friend who designs bridges (that go over rivers). He once told me that being off an inch cost a million dollars.
Without the four skills above – it doesn’t matter how smart the architect is, they will end up with a bridge that misses by more than an inch. The days of technology for technologies sake are over. The business is the driver as it should have been all along.
Language is a barrier that many people use and leverage as a way to avoid communicating.
But the real problem is the path to communication itself. How do we connect as human beings to provide that spark that is communication?
So when we consider communication and how we communicate its critical then we also consider what we are presenting as the data or information.
I’ve seen great presenters who stand and deliver almost any content, but they start out with the ability of great presentation skills. When they communicate they are used to having a net net of the data they are presenting.
Which of course is the data they are presenting and the value proposition of great presenters. What about good or average presenters. How can they achieve the same level of skill?
- Net out the message.
- what are you really trying to say
- Is that message clear?
Continue reading “The path to clear communication”
So Latte’s are nice. They mix espresso and foam. They can have chocolate shavings on top. you can get them in a to go cup.
Patterns and anti-patterns are of course not Latte’s. You can’t really drink either of them. But you can add cinnamon to your pattern…
The thing about patterns is that they are cookie cutter solutions that may not fit into the scenario you are considering..
On the other hand patterns allow you to have a flow and an overall process for what you are doing.
I believe personally that the pattern requires an architect to implement because of that balancing act.
Running a proof of concept recently I was struck by the name we were using. Proof, of a concept. A POC is merely proving that the solution as defined will in fact work. So what is a POC? It is proof. When you bring it into production it is then a pilot.
So why is that so hard to do? Why do teams constantly blur the line between POC (non-production) and Pilot (production)?
It intrigues me. We are struggling with the “profession” of software architecture. Not being consistent on what we say will continue to impact us. Part of a profession is having a clear glossary of what is acceptable in terms of the words you use.
POC – pre-production
Pilot – in production
Just be careful what you are testing, and where!
That the lifecycle of a solution was limited. Limited in the sense that the first time many things were deployed in IT environments they were solutions (web sites, intranets, mail systems) that later became components of the infrastructure.
This seems a silly debate but it is one that I see coming up again and again. Solutions are often mandates, or are budgeted separately than the infrastructure. This of course changes the world of the technology deployment. IT does upgrades, solutions are implementations. In an implementation you can have overruns and budget increases. In an upgrade you cannot have overruns without issues (well you can but it impacts IT much differently).
In reality however everything is a solution.
If we do leverage that approach the requirement there would be a solid enterprise architecture. Not an architecture of technology but actually a mapping of technology overlaying business requirements. The goal of business is to make money (or in the case of non-profits to not lose money which is the same as make money). If we take that simple approach to the mapping of solutions then the business justification becomes easier.
A solution may return its value in 36 months but it may enable two or three other solutions to be pulled forward that have much faster returns on investment. The cloud computing initiatives will in fact probably cost a lot of money initially. (see my blogs on transitional services) but may return 3 or 4 times the initial investment in overall reduced cost for the organization.