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.
What does an architect need to be successful?
Communications skills: both in writing and verbally. these are the skills that software architects use to communicate both the vision of the solution but also the implementation of that solution.
Leadership: There have been a number of initiatives in the world around this. For years organizations built teams of architects, led by architects. The feeling was that the architect manager would know the problems and concerns of the architect employees. Many companies are heading away from this – which is a huge mistake. Architects managing architects is a critical component of a successful architecture organization. The big gotcha is the managing architect has to have truly been a practicing architect at one time. I’ve been managed by architects before who had titles but no clue what architecture was.
Value driven solutions: Architects must understand the business requirements that lead to their solution being successful. This means not just knowing the specific problem being solved but actually understanding the business context of the problem. This leads back to communication skills, you may be selling against “the way things are.” Some business problems have been solved the same way forever. Therefore changing that solution takes some serious communication skills.
More to come…
When did I lose control of my solution? Suddenly its floating away – a cloud based doohickey with 4 9’s in its back pocket that has grown into a huge amorphous cloud hanging above me. When did I lose control?
I entered this project with the best possible intent.
Now it consumes me as though I were a tiny stick, used as kindling in a fire. Oh yeah there is no fire without me – but I cannot stop what has been created.
There is a plan of record. There is a plan for every possible issue and concern within this project. Yet it fails to stop. It is burning out of control.
Helpless you review everything you’ve done. Did you leave anything open ended? Did you end up not paying attention to the issues? Did you miss requirements?
How does a solution grow without control?
Well, the original proposed solution ultimately was not aligned with the business. And now you can’t control what is being deployed.
1/3 of IT projects fail.
I once had a PPC device that I used to play games on, and as a backup phone. Now I have a couple of devices I use – but the quality of the games and applications has improved so much.
My favorite game for years has been any one of the two puzzle games (Tetris and bejeweled). On the new 6.1 version of the Windows Phone OS – the quality of the games is so much better.
I find long plane flights now to be so much less boring then they used to be as recently as 5 or 6 years ago. From my Kindle to my Zune I can pass a number of hours easily – add movies to the Zune and the long flights to Asia just drift by.
The thing that companies and people are missing is the opportunity these devices present. The chance to work effectively on a plane. The chance to learn new things while whiling the hours away.
A cloud based, MP3 training solution that used Video Podcasts (via RSS) that you could have authenticated connections to – is the perfect solution for those long plane rides. First you put up a page that only the people you want to have the training can log into. Then you offer the training as a series of RSS feeds. Each one would be on a separate page, and you could put people into groups so that they could only see the content they had paid for.