Recently, I have come to believe that EA doesn’t introduce anything new to “modern business management”. However, such an approach to management seems to be rare compared to "classic business management". Consequenetly, I feel that EA is a bad solution to a deeper problem : "classic business management". Classic management is based on a tacit assumption that organizations can be compared to machines. Consequently, divide-and-conquer strategies are promoted both in organizational design as well as task responsibility/accountability distribution. This is to be expected because most “classic” management principles date from the industrial revolution. The consequence of all of this is that “classic” management doesn’t take a systemic approach to management (I’m using the term systemic from the perspective of Senge, Demings, etc.). In addition, as stated by Peter Drucker, classic management is about doing things right, it isn’t about doing the right things… that’s leadership.
If I go off into fantasy land for a moment :o) If organizations were managed using a systemic approach, there probably won’t be a need for an EA team. The EA team would be replaced by a strategic leadership/management committee with representatives from across all units (IT would be one). These representatives would work in collaboration in order to insure systemic optimisation and organizational learning.
Now back to reality… because of classic management, these units often do not work in collaboration because, driven by a culture of silos, they fight for limited resource in order to do what they believe is “locally” right instead of working together in order to do what is “globally right”. This is also sustained by a tacit assumption that accountability cannot be giving to a group but only to a single person.
Now if a talk about IT and EA. EA is probably often in IT because IT is always “stuck” in the middle of all the other units fighting for limited resources. Consequently, for IT to function efficiently, it has to compensate for the silo culture… hence the need for an EA team. Often, business management doesn’t understand EA because understanding it would put into question there ways on managing/thinking.
Thursday, May 27, 2010
Wednesday, March 31, 2010
Software - A social construct or a technological one ?
Over the last 60 years, we have tried to push the development of software from being a craft to an engineering discipline. Today, the expression “software engineering” is use commonly to describe the activities surrounding creating a dependable, functional piece of software. Despite the great advances which the software community has provided with regards to defining better controlled processes and methodologies for developing software, we often here people say that software creation is part art part science.
So… is it that we have not currently reached the holy grail of software development methodologies which will liberate us from the chains of the arts and crafts aspect of developing software, hence propelling us into a new age of software engineering nirvana….. or are we searching for a mythical dragon that doesn't exist ?
When we associate terms such as engineering, process, and methodology to the activity of creating software, we are implicitly casting software as a technological construct. A technological construct is an object which has meaning and existence outside the influence of people. At the opposite, a social construct only has meaning in the context of a society. For example, a bridge is a bridge. One can talk about a bridge without making reference to a given social context. In contrast, one cannot talk about concepts such as “respect”, goodness without making reference to a given societal context. Each social group will define what it means to “respect others” differently. Technological constructs can be define rigorously using symbols such as mathematics and blueprints to define what they are... they can be engineered.
I have been recently pondering the idea that software is mostly a social construct; especially software developed in the context of organizations. In these contexts, software often plays the role of a human being (albeit an automate one) participating in business processes characterised by complex webs of interacting individuals. Moreover, these processes are most often executed in similar ways but never exactly the same because contexts are never the perfectly the same and people never behave the same. In order for complex tasks such those found in organizations to be accomplish by teams of people, it is necessary for the team to develop “shared meaning” about what most be done and how they should work together. This “shared meaning” about the “what” and the “how” is a social construct… it is establish through dialogue and shared experiences amongst the team members. If software must take part in one of these webs of human interactions because it replaces one of the team members, one could probably argue that “what” the software should accomplish and “how” it should to it is also a social construct because different social contexts (organizations) will probably have different “shared meaning” on the matter.
If this is such, software is a social contract. Consequently, one can only define software through a continuous dialogue of “shared meaning” creation. The process of using upfront specification which are than used to “engineer” the final product cannot work… only iterative process which verify often the congruence of the software with the “shared meaning” of role it should play can work…..
So… is it that we have not currently reached the holy grail of software development methodologies which will liberate us from the chains of the arts and crafts aspect of developing software, hence propelling us into a new age of software engineering nirvana….. or are we searching for a mythical dragon that doesn't exist ?
When we associate terms such as engineering, process, and methodology to the activity of creating software, we are implicitly casting software as a technological construct. A technological construct is an object which has meaning and existence outside the influence of people. At the opposite, a social construct only has meaning in the context of a society. For example, a bridge is a bridge. One can talk about a bridge without making reference to a given social context. In contrast, one cannot talk about concepts such as “respect”, goodness without making reference to a given societal context. Each social group will define what it means to “respect others” differently. Technological constructs can be define rigorously using symbols such as mathematics and blueprints to define what they are... they can be engineered.
I have been recently pondering the idea that software is mostly a social construct; especially software developed in the context of organizations. In these contexts, software often plays the role of a human being (albeit an automate one) participating in business processes characterised by complex webs of interacting individuals. Moreover, these processes are most often executed in similar ways but never exactly the same because contexts are never the perfectly the same and people never behave the same. In order for complex tasks such those found in organizations to be accomplish by teams of people, it is necessary for the team to develop “shared meaning” about what most be done and how they should work together. This “shared meaning” about the “what” and the “how” is a social construct… it is establish through dialogue and shared experiences amongst the team members. If software must take part in one of these webs of human interactions because it replaces one of the team members, one could probably argue that “what” the software should accomplish and “how” it should to it is also a social construct because different social contexts (organizations) will probably have different “shared meaning” on the matter.
If this is such, software is a social contract. Consequently, one can only define software through a continuous dialogue of “shared meaning” creation. The process of using upfront specification which are than used to “engineer” the final product cannot work… only iterative process which verify often the congruence of the software with the “shared meaning” of role it should play can work…..
Subscribe to:
Posts (Atom)
Posts
