Category: Softwares

97 Things Every Software Architect Should Know – 17/97

In the context of business enterprise application development, an Architect must act as a bridge between the business and technology communities of an organization, representing and protecting the interests of each party to the other, often mediating between the two, but allowing the business to drive. The business organization’s objectives and operating realities should be the light in which an Architect leads technology-oriented decision making.

Businesses routinely plan for and articulate a specific, desired Return on Investment (ROI) before undertaking a software development initiative. The Architect must understand the desired ROI, and by implication, the limits of the value of the software initiative to the business, so as to avoid making technology decisions that could cause the opportunity to be out-spent. ROI should serve as a major piece of objective context in the give-and-take conversations with the business about the value of a feature versus the cost of delivering that feature, and with the development team about technical design and implementation. For example, the Architect must be careful to represent the interests of the business to the development team by not agreeing to choose technology that has unacceptably costly licensing and support cost implications when the software is deployed into testing or production.

Part of the challenge of letting the business ?drive? is providing enough quality information about the ongoing software development effort back into the business to support good business decision making. That‘s where transparency becomes crucial. The Architect, in conjunction with development management, must create and nurture the means for regular, ongoing information feedback loops. This can be accomplished by a variety of lean software development techniques, such as big visible charts, continuous integration, and frequent releases of working software to the business starting early in the project.

Software development is fundamentally a design activity, in that it involves an ongoing process of decision making until the developed system goes into production. It is appropriate for software developers to make many decisions, but usually not to make business decisions. However, to the extent that the business community fails to fulfill its responsibility to provide direction, answer questions and make business decisions for the software development team, it is actually delegating the making of business decisions to software developers. The Architect must provide the macro-context for this ongoing series of micro-decisions made by developers, by communicating and protecting the software architecture and business objectives, and seek to ensure developers do not make business decisions. Technical decision making un-tethered to the commitments, expectations and realities of the business, as articulated by the business community on an ongoing basis, amounts to costly speculation and often results in an unjustifiable expenditure of scarce resource.

The long-term interests of the software development team are best served when business drives.

97 Things Every Software Architect Should Know – 16/97

It seems to be a never–ending source of surprise and distress to system builders that one data model, one message format, one message transport—in fact, exactly one of any major architectural component, policy or stance—won’t serve all parts of the business equally well. Of course: an enterprise ( “enterprise” is red flag #1) big enough to worry about how many different “Account” tables will impact system building next decade is most likely too big and diverse for one “Account” table to do the job anyway.

In technical domains we can force uniqueness. Very convenient for us. In business domains the inconsistent, multi–faceted, fuzzy, messy world intrudes. Worse yet, business doesn’t even deal with “the world”, it deals with people’s opinions about aspects of situations in parts of the world. One response is to deem the domain to be technical and apply a unique solution by fiat. But reality is that which does not go away when one stops believing in it, and the messiness always returns as the business evolves. Thus are born enterprise data teams, and so forth, who spend all their (very expensive) time trying to tame existential dread through DTD wrangling. Paying customers tend to find the level of responsiveness that comes form this somewhat unsatisfactory.

Why not face up to the reality of a messy world and allow multiple, inconsistent, overlapping representations, services, solutions? As technologists we recoil in horror form this. We imagine terrifying scenarios: inconsistent updates, maintenance overhead, spaghetti–plates of dependencies to manage. But let’s take a hint from the world of data warehousing. The schemata data marts are often (relationally) denormalized, mix imported and calculated values arbitrarily, and present a very different view of the data than the underlying databases. And the sky does not fall because of the non–functional properties of a mart. The ETL process sits at the boundary of two very different worlds, typically transaction versus analytical processing. These have very different rates of update and query, very different throughput, different rates of change of design, perhaps very different volumes. This is the key: sufficiently different non–functional properties of a sub–system create a boundary across which managing inconsistent representations is tractable.

Don’t go duplicating representations, or having multiple transports just for the fun of it, but do always consider the possibility that decomposition of your system by non–functional parameters may reveal opportunities to allow diverse solutions to your customers’ advantage.