Posts

Showing posts from November, 2006

The cost of politics on software development

My gut feeling is that organizational politics introduce a 25% overhead on all software development projects. I strongly feel that a formula can be devised to determine the cost of politics on software development. As a matter of fact when I pondered pursuing a Ph.D. in software engineering I thought this may be a worthwhile topic to explore. The reason this subject matter is brought up in this blog is because politics are unspoken constraints on a project.The software architecture practitioners are finally maturing to a point where system’s quality attributes are measured in a meaningful way. For example, to express performance requirements of a certain aspect of a system an architect would create a scenario that may sound something like this: “8500 users stochastically add one item per minute to their shopping cart while the system operates in the ‘holiday shopping mode’ and the requests are processed with an average latency of 3 seconds.” A series of such scenarios provide a wo…

Listen. Observe. Think. Speak. When passion limits your potential.

This post is a reflection on the past behavior that landed this firebrand architect into a counterproductive situation and, temporally, put him in a penalty box. Let this be a warning to others. Before joining this project on a full time basis I was invited to spend time evaluating the existing architecture and make recommendations before the development phase would commence. During the architecture review & analysis process I have identified a number of risks, in light of project constraints, including application’s laborious authentication and authorization requirements. To address this risk I proposed integration of a well known .NET compatible COTS software access control and authentication component. Luckily the organization’s Enterprise Architecture (EA) has already authorized utilization of such component, and even already possessed an enterprise license for its use.A large (eighteen person) meeting was called to discuss future placement of the solution in development, t…

Information sharing / architecture documentation sharing

In a survey taken by SoftwareArchitectures.com in the spring of 2006 over 65% of the visitors were most interested in seeing practical examples of software architectures. The architecture of the real world enterprise grade software systems is proprietary as it represents the competitive advantage of an organization. Therefore it is difficult to obtain software architecture documents of such caliber, which consequently hinders information sharing between software architecture professionals.But it is still possible to share the essence of software / system architecture without compromising organizational secrets. To achieve this, first, complete anonymity of the submitter must be assured. Second, the proprietary information must be rewritten or removed (e.g. IP addresses, company name, product name, interface systems, etc.). Third, the business problem solved by a system must be generalized. Fourth, implementation specific information must be removed to a level that does not give away o…

One year of experience many times

While at the CarnegieMellonUniversity pursuing a Masters degree in IT - Software Engineering one of my professors said: “You can have 20 years of experience or you can have one year of experience twenty times.”It is easy to become a victim of monotony at an organization with well established processes where all software projects move in a similar cycle. This is especially true in government, non-R&D, and non-startup organizations. Further, once an architect becomes comfortable with a given technology or a set of tools he or she may be unwilling to consider alternative approaches to solving a slightly different problem. For example, if a software architect just finished designing a complex system using the Model-View-Controller (MVC) architectural pattern with a team of experienced software engineers, he or she may automatically select the same approach for a subsequent system. But what if the subsequent system is simpler and is staffed with software engineers freshly out of colleg…

Different paths of ascension

It is common to hear software architects draw parallels between physical building design and software system design. The analogy suffices to a certain extent and is a subject of a different post. However, the author of this post is interested in the path of ascensions between the two professions. The contrasting difference is that a software architect almost always starts as a programmer learning & testing the composition of the building blocks. A building architect starts his or her path on a high level - normally without spending time working as a bricklayer at a construction site. The curriculum of a building architect includes courses on structure, design, environment, and history followed by hands-on learning of CAD tools that support the work.Now looking at a standard computer science curriculum one would notice that very few courses actually cover the concept of software architecture. Such courses are taught on a graduate level and are normally part of a graduate level…

When you’re positioned for a sprint

There are some projects that run like a well oiled machine. The necessary resources are available, the management fully supports the initiative (i.e. fully funded), all team members understand and faithfully execute their roles, and the planned software system victoriously emerges with tolerable defects. And then there are projects that are dysfunctional. For example, team members are forced to develop software without receiving any training on the chosen technology, schedules are created with little consideration for the envisioned architecture, and fundamental project management practices are not exercised… There are many case studies (examples available per request) documenting eventual demise of such projects unless a champion rises to the challenge and takes the lead. As an architect, especially if you’re an aspiring architect within your community, you may be provided with an opportunity, or forced, to take the challenge of saving the day.As an architect with leadership respo…