Posts

Showing posts from 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…

Wiki for a software architecture document

Wikipedia has revolutionized the way information is generated, edited, and made accessible to various Internet audiences. Wikipedia, a publicly edited encyclopedia, is based on a concept of wiki where any user can edit any information at any time. This ad hoc approach sounds like a bad idea, but it may be useful for designing and documenting software architecture – democratically. The primary goal of the wiki solution is to make the system’s software architecture document a living document so that it can accessed and used effectively by all system stakeholders.

Compared with the industry’s “standard” approach to documenting software architectures (advanced word processor [MS Word], drawing software [Visio], and source control [CVS]) the wiki approach provides the following benefits. The document is accessible via any web browser, transclusion allows for repetition of information defined earlier in a document, source control and mechanism for merging & discussing changes are built-…

Deployment view: documenting the essence of the target environment

Sufficiently documenting software design, including source code, is essential. But sufficiently documenting fundamental software architecture views is critical. There are many views to consider during design and analysis of a system. This time a basic deployment view is discussed.A simplified deployment view is a high level tangible mapping between system elements (e.g. messaging queue) and physical hardware spread across network topography. One of SoftwareArchitectures.com colleagues, PJ, observed the following situation at his current client engagement. The task of overseeing the deployment of a significant iterative release into the test environment was assigned to the associate architect of a system. The client’s environment features institutionalized configuration management policies that can be circumvented when pushed, but the deployment manager has no access the system directly. The test environment administrator, who physically controls the test environment, is only available…

This blog: what's in it for you?

The motive behind this blog is to expose the human aspects of the software architecture discipline and how they fit into the overall software development process. Due to purposeful omission of technology specific details the blog targets programmers, developers, project managers, students, interns, junior and seasoned software architects alike.

Some of the observations and conclusions may seem obvious and familiar as they have been documented in classical software engineering books such as Fred P. Brooks’s The Mythical Man-Month: Essays on Software Engineering, Roger S. Pressman’s Software Engineering: A Practitioner’s Approach, and Ian Sommerville’s Software Engineering. Further, some of the problems & solutions may not seem to be architectural in nature at all. That’s precisely the point. The goal of the prose is to expose the obvious and to prod the reader to ask oneself if a given scenario or a point of view is applicable to own situation. If just one reader sees personal valu…

What is firebrand?

DESCRIPTION OF THE FIREBRAND“The firebrand is the person who recognizes what is natural, what is organic, what is alive and vital in life, the person who dares to live, to be, and to create, often in the face of interference, rejection, deceit, and betrayal. The firebrand is a burning ember, life that is in each of us and that provides the spark and energy to speak against what distorts, hides, and denies our being and truth. It is that which awakens within us, when we must declare our independence or when we discover a new formula for living. It is the path that enables us to participate in the mystery of creation, uniquely and individually. The firebrand expresses her- or himself in two basic ways: as the torch that lights up the darkness, and the as the carrier of the torch, throwing light into the darkness, and often disturbing complacency and brewing trouble. Being a firebrand is a way of raising temperatures and creating conflict, turbulence, and dissension.The motive of the fir…

From the trenches...

The time has come for the stories from the trenches ...