One of the things that I have observed over the course of this century is the transition away from traditional “Data Processing” titles like programmer, programmer analyst, systems analyst, etc. The key evidence of this trend is the proliferating of self-aggrandizing titles involving the term architect. In 1985 when I graduated, I don’t remember every hearing of a software architect or a network architect, or God forbid an enterprise architect or an application architect or a solutions architect or any such thing.
I suppose it started with the transition from Mainframe style computers toward what we now refer to as distributed systems. First everything was mainframe and dumb terminals, then it was PC’s. Then it was networks of PC’s and Servers. For a while it was Client/Server and then multi-tier or n-tier and finally the generalization of the term distributed systems. Different computers doing different parts of the work in different places, mostly by “collaborating” with each other.
The programmers who worked on distributed systems had much more diverse titles. They were software developers, application developers, database developers, user interface developers, and with the advent of the internet and the world wide web, there were web developers. Back in the day, there were programmers who worked on the internals of systems that no user would ever see. Those people were called systems programmers, now in the age of distributed systems, their new self-aggrandized title was software engineer! Then as these servers and n-tier platforms started to become more complex, every server product needed a dedicated administrator so the unix operating system need a unix admin and the database needed a database admin and pretty soon we had java “containers” that needed their own admins. The networks that connected all the computers together needed administrators and pretty soon the whole thing got very complicated.
As these systems grew more and more complex, we started to realize that the genius-wizards who were good enough at their job to be able to see the big picture and to help us straighten things out when they got wrapped around the axle deserved a special title “Architect”. This brings me to the ultimate question for this blog post:
“What the hell does an architect have to do with information technology?”
Read more ›
When you look at software development or corporate change projects, you often see some creative fiction. There is fiction in the plans, fiction in the designs and fiction in the requirements. This fiction is created by the notion that “Before we can start, we have to know everything required to get to done.”
Intuitively, we all know that this is not really true. We all know that information will “emerge” from our activities that will change how we get to done. We learn from our mistakes. We try things that don’t produce as good a result as we want. We clarify our understanding of the problem as we demonstrate portions of the solution. Read more ›
I have been away from this blog for a while. In fact, I don’t remember when I last posted (I looked it up it was May.) In my hiatus, I have worked on some other writing projects and spent some time with Zed A. Shaw’s excellent “Learn Python the Hard Way”. As a matter of fact I. will post my impressions of that book soon. Preview: It is an interesting take from an interesting guy at solving the coding bootstrap problem.’
Today I want to talk about something else that has been bothering me for a while. The notion of an elastic software delivery staff. This is not a new problem, in fact, it is as old as software. Fred Brooks wrote “The Mythical Man Month” almost 40 years ago, based on experience almost 50 years ago. I was introduced to that book in 1984 while I was studying computer graphics with Sam Uselton at the University of Tulsa.
When you haven’t tried to “run” a software delivery team or project, the tremendous wisdom in that book pretty much goes in one ear and out the other. You don’t have the experiential context to comprehend the problem space. When I read Scott Adams brilliant Dilbert comic strip today, I see much of the same problem space. There are types of work that don’t scale well. Our traditional strategies for elastic staffing that developed during the industrial age don’t really work effectively for this kind of work. Read more ›
Current group I am working in is responsible for functional architecture. In spite of the fact that I don’t have any practical experience, I have been asked to help define a practice in Business Capability Modeling.
I think the reason for that is that I have some practical insight into the requirements that functional architecture or functional systems design places on a business capability model.
The most core principle of functional architecture involves the semantics of units of work. In fact business capability modeling is about defining the semantics of units of work – so there is my connection point. Read more ›
I recently spent some time working my way through “Learn Python The Hard Way” by Zed A. Shaw. Zed is a programmer who has accomplished more than most in his short time on Earth. He is outspoken and often edgy, and has a reputation for being both brilliant and blunt. Zed is the creator of the Mongrel server engine that powers many Ruby on Rails sites.
Zed comes off as a Hard Ass, more than anything, and his proposed methodology to learn programming is hard, as in hard assed, not hard as in difficult. Learn Python The Hard Way is old school. Which is good, because I am old. It reminds me of learning Fortran in my freshman year of college in 1980. Hollerith cards. 039 keypunch machines. All batch processing. When you are dealing with “physical” cards, and physical sorting of program steps, and waiting an hour to see if your code compiled, let alone executed to completion or got a correct answer you tend to do alot more “desk checking” than we do today. That is the thing that I like about LPTHW is that it teaches some technique around old school desk checking. Like reading your code backwards to find errors, something that we often did on green bar paper at a table at Helmut’s Alpine Kitchen at two o’clock in the morning with a pot of coffee and an order of biscuits and gravy. Read more ›
Its 2014, almost 2015 and conventional wisdom about computers and programming have changed dramatically in the last 30 years since I graduated college. The number of people who use computers have changed from 10% to 90% in that period of time. My Google Nexus phone has way more memory and compute power than the mainframe I learned programming on in college. The PC that I bought in 1986 had a 20 megabyte hard drive – that would hold about 10 images shot on the camera embedded in my phone, or one shot in raw mode on my DSLR.
In the 1950’s into the 1970’s, computers were physically large, occupying large rooms and requiring many attendants or operators to manage. In the 1970’s the microchip or integrated circuit technology allowed computers to be built that would fit on a desk. Now we all need a laptop, a tablet and a phone and maybe a watch or a pair of glasses that are all computers of some kind. We have computers in our cars, smart homes. All our video gaming consoles are just computers.
Conventional wisdom which 30 years ago saw that computer programming was a highly specialized skill, now sees that everyone should learn how to code, even if they don’t do it very often. This is because as computers become more ubiquitous, we need to understand them – the same way that every should know basic auto maintenance like changing the oil or mounting the spare tire when you get a flat. The same way we know how to unclog a toilet or sink drain or oil squeaky hinges in our home. Computers are so much a part of every day life that we need to understand more about how they work.
So lets just accept the conventional wisdom for a moment. What does learning to code mean? What is code exactly and how does one learn it? Read more ›
Sometimes in life and work, we become convinced of a need to change before most of those around us. Either we read the tea leaves, or we see the bigger picture, or some how we just were able to jump through the problem straight to a potential solution. Maybe we have worked through all the analysis in our mind and have a detailed idea that could be a slam dunk, a quick win, or a major turn-around for the organization. The problem is simply that everyone else is stuck in the status quo. Maybe they don’t see the problem clearly yet, maybe they just are not willing give what change requires – or maybe they just see the obstacles to change as being unavoidable or worse, unforeseeable. Maybe they see the risk of the change as many times larger than the risk embedded in the problem.
You have tried telling them. You had tried to convince others that your idea is good, that it will work. You have “told them until you are blue in the face.” Somehow, you end up coming off as unhelpful. People generally get defensive when you try to tell them about the problem, you can’t even get the solution on the table.
Perhaps the issue is not that your analysis is weak, or your solution is not worthy, but only that it is not shared. How do you get others to share your perspective, and to help champion your ideas? How do you get them to understand that the status quo (which they have been working hard to build and keep going) is going to turn out to be insufficient to achieve the larger vision? How do you get them to “disinvest” themselves in the way things are, so that they can invest in a new idea? How do you get them to be open to your ideas, instead of getting defensive? Read more ›
Functional Architecture as a discipline has been brewing for a few years now. I have been a “functional architect” for a software application, and have also been involved in functional architecture review of enterprise software programs. I won’t claim to know what functional architecture means in any universal sense, but having done this work, and been in this role, I can describe some functional architecture principles that I know are helpful to making software more valuable in an enterprise context.
Functional architecture has several aspects. Read more ›
In a recent post about consulting engagements, I talked about some of the challenges with consulting organizations and their standard practices. I thought maybe some might benefit from some insight. These are some specific suggestions for handling these kinds of challenges.
1) Consulting firms have “relationship” managers or “engagement” managers – these are people whose job on the project it is to ensure the customer is satisfied. It is their corporate mission to ensure that your company spends more money with them. They are sales people. They come to your project meetings, with a stated purpose of making sure that the project is smooth and successful. Their “other” purpose is to develop a deeper network in your organization, and to “discover” other opportunities for their firm to “help”. While they may have expertise, industry knowledge, and skills that help your organization, it is worthwhile to question whether they should be billable on your engagement. Read more ›
My current role is interesting. I am an internal IT consultant in a large financial corporation. As an internal consultant I am free to work on as many projects as I can juggle. My billing is only explicit when I work on capital projects. I spend more time talking than “working”. Most of my working is writing. Yes, making PowerPoint decks is considered writing.
Over the past year, most of my own internal consulting engagements have involved some coaching. Coaching leaders on the business side of our organization through projects with IT entanglement. Coaching IT leaders through adoption of new technology or practice patterns. Coaching project leads into positions of transparency and truth telling. Coaching different kinds of leaders through developing guiding principles that make all the little decisions easier. Interestingly enough, the coaching is not really what I was engaged to do. It simply flowed from my understanding of the needs of individuals in the project context to be successful.
Recently, I have been working with a number of external consultants. Teams, actually. Teams of consultants from big 5 firms. I have been attached to the same project as they have, and to them, I am a SME and a network adapter. I share my knowledge of organizational practice and my interpersonal network with them, so that they can get their deliverables accomplished.
What I often struggle with is the shallow depth of their analysis. Their engagements are short, usually in increments of 6 week intervals. They spend a lot of time collecting data but not really producing information. They have methodologies that I suppose would be effective if the data/information they were fed were appropriately scrubbed and semantically understood. Read more ›