Another Useless Acronym (AUA)
Another Useless Acronym (AUA) or what can happen when partially formed new architectural ideas emerge.
Automagically
When something has the capability to perform an indispensable task that no one thought was even possible.
Bottom Up Design
Bottom up design, as with its counterpart Top down design, are strategies of information processing.
In the Bottom up design approach, individual parts of a system are designed in detail and the design parts are then linked together to form larger components, which are then in turn linked until a complete system is formed. Often the bottom up approach assumes that all facts are known up front as the detailed parts are designed.
In the Top down design approach to modeling an overview of the system is made, without going into detail and each part of the system is then refined by designing it in more detail. Each new part may then can be refined again until the entire specification is detailed enough. Often the top down approach is used when not all facts or constraints are known about a design.
Choreography
Formally a choreography can be defined as a declaration of the activities within collaboration and the sequencing rules and dependencies between these activities.
Often these days, when people talk about the architecture of business services there are 2 related concepts which often come up - choreography and orchestration.
The difference between the two is easy to remember depending on your design perspective. Seen from a publicly observable view of a service, choreography is the description of how to interact with the service to consume its functionality. Seen from the same publicly observable viewpoint, orchestration is how service functionality is achieved ("within" a service) by aggregating some service logic and very possibly other Web services.
Cycles
Time, resource and effort that ought not to be wasted. "Let's not waste any cycles on something that doesn't matter."
A portion of one's capacity to perform work. "Do you have any cycles to burn on the ...".
Drinking from the Fire Hose
Having an overwhelming amount of information thrown at you, commonly at the start of a new job or project.
Ivory Tower Architecture
An architecture developed in isolation from the developers, or teams of developers, responsible for following it.
KISS
Keep It Simple Stupid is a design philosophy that states simplicity lasts and simplicty is needed to properly convey any ideas. Simplicity is the absence of unnecessary elements. Simplicity isn't a design style, but a perspective on design and an approach which often creates the most usable and beautiful results.
Low Hanging Fruit
Management expression for the most available and easy to accomplish objectives.
Operational Requirements
A category of requirements that describe the operational expectations for a system, such as availability, security, performance, scalability, manageability, interoperability, and reliability.
These requirements are distinct from the functional requirements that detail the business functions that the system performs (e.g., calculating the total bill for a shopping basket).
Also called "non-functional requirements"; also called "non-behavioral requirements". Closely related to the concepts "aspects" and "qualities".
Portfolio Management
Portfolio management is a function of IT Governance (which makes it fair game for enterprise architecture). The portfolios in question typically include both the application portfolio and the service portfolio. The focuses of portfolio management typically include:
- Redundancy analysis -- avoiding having (and paying for and maintaining) multiple artifacts that perform essentially the same function;
- Gap analysis -- identifying opportunities to improve processes through better automation;
Manageability -- standardization of management interfaces, including vendor selection based on adherence to standard metaphors for management; - Cost rationalization -- analysis of the true ROI of automation and elimination of non-cost-effective systems;
- Server consolidation -- reduction of the number of systems being supported, often by standardizing to a small set of server operating systems.
Project Stakeholder
Project stakeholders are any of the interested parties in a given development project. Typical examples of stakeholders include:
- Business process owner -- the person responsible for the profit-and-loss of the business process being supported;
- End user -- the people who will actually use the system under development;
- Operations -- the people with the pagers whose sleep is at risk;
- Executive sponsor -- the person who can light a fire under non-responsive stakeholders;
As well as architect, project management, developers, and testers, naturally.
Quality
The term "quality" is used in two distinct ways in systems architecture. The first usage is to define a class of common properties that must be addressd by any system. These "qualities" include:
- Security
- Manageability
- Availability
- Reliability
- Scalability
These system qualities may be cross-cutting concerns for the system, and hence may be best addressed using some form of aspect-oriented programming.
The second usage is closer to the typical English-language usage: how well the system meets the requirements that were defined for it. For a more complete look at this meaning, please see quality management.
Rat Holing
A slang term for a discussion that spirals away from the topic of the meeting.
Return on Investment (ROI)
A calculation of the economic value being derived from a system as compared to its costs.
When embarking on a new initiative, it is common to predict an ROI for the system under consideration. This calculation needs to look at both development and ongoing operational costs for the system. The calculation is used as a justification for moving ahead with the project.
Once a system is in operation, ROI calculations ignore the "sunk costs" of development, and only compares the value being realized with the ongoing costs (which are more fully understood once the system is in operation than it was when the project was being envisioned). This calculation may, however, consider depreciation of assets that support the system, such as computers and storage devices.
Taxonomy
A taxonomy is a system of classification and with context, such as enterprise or folks or something else, a taxonomy is a description of the context.
Time-to-Value
Time-to-value is the elapsed time between the commitment to a project and the perceived realization of value from the investment. Project planners who stress short time-to-value seek to maintain excitement and emotional engagement around the project. Long lags between project inception and perceived first value can cause business process owners to disengage from and deprioritize the project.
Waterfall
Waterfall processes proceed through a unidirectional sequence of discreet steps.
The term is principally applied to a software development methodology that promotes a sequence along theses lines:
- Conceptualization -- business process owners identify a business need and develop a conceptual model for a solution;
- Requirements definition -- solutions architects work with business process owners to produce a detailed functional specification;
- Project definition -- the functional specification is used to generate a set of work items for development;
- Development -- Developers and test engineers produce and validate a set of deliverables in accordance with the project plan;
- Acceptance testing -- the resulting system is tested for compliance with the functional requirements;
- Deployment -- the system is put into production.
Critics of waterfall methodologies question how effectively the requirements for a software system can be understood "up front". They promote more agile approaches to software development.
