Speaking at Momentum in Prague

I will be speaking at Momentum in Prague. More details to follow

Enteprise Solution Architecture – “architecture of the architectures”

Enterprise Solution Architecture Framework

Solution Architecture is a process within the Enterprise Architecture that focuses on the development and implementation of a solution or service being created for the enterprise.The Solution Architecture framework is a combination of structured processes and templates that utilize existing architecture documents (such as business, information, and technology components as well as models and patterns) to design a desired business solution. The Solution Architecture framework, by allowing the development of a Solution Set, facilitates the rapid development and delivery of a solution in a systematic and well-disciplined manner. 

The ESAF deals directly with arguably the single most important and challenging architectural issue: combining and reconciling the loosely coupled and often conflicting viewpoints of the primary stakeholders into a unified architecture for an enterprise solution that actually solves a business problem without creating other, even larger, problems. It is the “architecture of the architectures”.

Enterprise Search Requirements

•  Support federated search of multiple sources, including file servers, web, e-mail, enterprise application data and reports, records within databases and the content management system.

•   Have the ability to control access to items of content from search and/or site map indexing based on AOC business rules or security roles (i.e. users shall only see results to which they have access).

•   have the ability to integrate simple and advanced search screens and result screens into the user interface.

•   control the discoverability of content items by external search engines.

•   have the ability to generate a plain English URL for key web pages for easy referencing by non-technical end users and search engines.

•   have the ability to interface with thesauri or allow import of thesauri data into search engine thesaurus for browsing, selection and searching.

•   provide a soundex (sounds like) capability in the thesaurus function so that misspelled terms can be related to their correct spelling.

•   provide comprehensive search facilities across the entire website, multiple sites or sub sites to support content publishing.

•   retrieve results in a timely fashion: goal is to ensure that tool adoption will not be negatively impacted by the speed at which it returns results.

•   support “pre-processing” of all search terms against the thesauri and automatically include related terms in the search.

•   have the ability to query and retrieve standard metadata.

•   support automatic indexing, keyword generation, and full-text indexing.

•   support comprehensive external search facilities across the entire website, multiple sites or sub sites for end users.

•   support key word and metadata search.

•   support multilingual search.

•   support separate indexing of content items for each supported website.

•   support the automatic modification of search results based on site usage and search patterns (e.g. weighting the most popular sites/search results selected by the user to appear high in the search results list).

•   support the measurement of the use/effectiveness of each keyword search query entered by a user in searching the website. This capability may be provided by a third party web metrics facility.

•   support natural language search interaction

•   support case independent search

• Systems shall conduct present partial matches (2 words out of more) after exact matches and occurs-in-page matches

• Support the use of Boolean operators (and; or; not) and proximity operators (near; with) to refine searches and accept phrases for full-text searches.

•   provide the ability for the CMS to control display of and access to items of content from search and/or site map indexing based on AOC business rules or security roles (i.e. users only see results to which they have access)

•   provide the ability to search by learning object or learning object type

•   support indexing of text and common attachments (including Microsoft Office documents, Adobe PDF, etc.) within the CMS and across a number of repository types such as file systems and databases.   Detail any formats not supported by system indexing.

•   allow end user to create and save searches.

•  provide a user interface to allow users to customize the sources included in a given search scope.

•   support highlighting of search terms within a result set or document.

•  provide control parameters that allow the administrator to control connection performance to content so that, for instance, a live Web server indexing can be throttled back so that indexing does not crash the server (but a file server may have a different control setting which allows for potentially faster retrieval during indexing, depending on network connectivity.)

•  provide configurable search indexing schedules to allow administrators to set indexing at various times so they do not conflict with scheduled downtime of servers (for nightly backups).

•   provide reporting features to enhance search engine results sets and design.

Database design checklist

Naming Conventions
Check as prescribed by Design Standards.
Graphical Representation
Is a graphical representation available?
Is it consistent with the other documentation?
Can it be used by the build team?
In what ways does the logical model differ from the conceptual schema?
Completeness of Specification in Design tool
Which slots in the design tool screens have been left open?
Why?
Choice of Database Objects
Have particular database objects been avoided or not used?
If so, then why? (Think of views, sequences, sequence number tables, indexes.)
Interpretation of Conceptual Schema
Do the logical and physical models cover all and only the conceptual schema?
Have all non trivial translations been adequately documented?
Can this interpretation easily be used in a Generator environment?
Table Definition
Check as prescribed by Design Standards.
How have super‑ and subtypes been handled?
Is the table usage valid with respect to the CRUD matrix.  (Note that a table may be modified through a view.)
Has the life cycle of all tables been covered completely by the modules?
Column Definition
Check as prescribed by Design Standards.
Have domain definitions been used correctly?
Have the datatypes been defined according to the standards?
Are system generated keys used?
Is the column usage valid with respect to the CRUD matrix?  (Note that a table may be modified through a view.)
Is the life cycle covered completely by the modules?
Have datatypes been chosen adequately?
How will status columns be handled?
Constraint Definition
Pay attention to constraints that only hold for subtypes, or that hold under special conditions.
Check if there is no overlap between constraints.
Have all necessary constraints (PK, FK, CHECK) been defined on views?
Definition of Relationships
Check as prescribed by Design Standards
Investigate the following:
the design of arcs
non transferable relationships
recursive relationships
time‑dependencies
(Which time is used, commit time, screen time?  What operations may be performed on time‑dependent data, under what conditions?)
Definition of Other Database Objects
Have other objects (views, indexes, domains, sequences) been defined completely and consistently?
Is there some unusual distribution or other property of the data that makes the use of these objects (un)necessary?
Special Problems
Have special measures been taken to deal with the following:
journaling
(What data will be journaled:  user, session id, object, operation or module, and how?
Will the journaled data be used for “rollback to X” or “roll forward from X” purposes ?)
high performance demands
(response time for reports, screens, overall response time, partial)
heavy or peak usage, high throughput
complex mix of hardware
robustness
denormalisation
non‑frozen data model, out of phase development of other systems
long or raw columns (in a network environment)
concurrency problems
distributed data
interface with external systems (database / non-database)
expiration dates
handling of NLS support (for example multi-lingual, multi-currency systems, different date or number notations)

Stakeholder Analysis

Influence

Influence is defined as the extent to which a stakeholder is able to act on project operations and therefore affect project outcomes.  Influence is a measure of the power of the stakeholder.  Factors likely to lead to higher influence include the extent of control over the project funding and the extent to which the stakeholder informs decision-making around investments in technology and workplace productivity.  A simple scoring system should be used of lower influence (1) or higher influence (2).

 

Importance

Importance is defined as the extent to which a stakeholder’s problems, needs and interests are affected by project operations or desired.outcomes.  If ‘important’ stakeholders are not assisted effectively then the project cannot be deemed a ‘success’.  Again, a simple scoring system should be used of lower importance (1) or higher importance (2). 

The Power Grid (example for a typical Portal Project)

 

The overall ‘Power Score’ is simply a product of the importance and influence scores.  The following 2×2 matrix summarises – for ABC Co – the respective power positions of the stakeholders for the intranet portal project:

 

Higher Importance, Lower Influence (score: 2)  Communications DirectorProcurement DirectorMarketing DirectorIndividual Employees	Higher Importance, Higher Influence (score: 4)  Chief ExecutiveHR DirectorFinance Director
Lower Importance, Lower Influence (score: 1)  Company SecretaryExternal Suppliers	Lower Importance, Higher Influence (score: 2)  IT Director,Line ManagersExecutive PAs

 As one may observe, the importance and influence of certain individuals implies that they will be “key stakeholders” for the project as a whole.  Without their explicit support, it is unlikely that the project could be concluded successfully. 

Stakeholder Approach

 The position of the stakeholder on the Power Grid tends to determine their initial and ongoing role in the project.  At least one (and preferably more) of your score 4 stakeholders should really sponsor your business case and sit on the project steering group.  As such, they are “key sponsors”.  Many of those with a score of 2 will be “secondary stakeholders”. Having determined their relative positions, the next key step is to plan out how you are going to manage each stakeholder during the project.  There are four general techniques at your disposal: 

Partner

Key stakeholders (with high influence and importance to project success) are likely to provide the basis of the project ‘coalition of support’, and are potential partners in planning and implementation. In the example, this coalition of support includes both the HR and Finance Directors. 

Conversely, key stakeholders with lower influence or importance to project success may be ‘managed’; by being consulted or informed:

 

Consult

The opinions and input of the stakeholder will be actively sought for certain key decisions (and not only those which may affect them directly).  Generally, this approach will be appropriate for sponsors with higher influence but lower importance (e.g. the Line Management community in our worked example).

 

Inform

The stakeholder will be informed of decisions taken (generally only those which may affect them directly), but it is unlikely that they would play an active role in making those decisions.  However, were they to highlight a particular issue with a decision, it is likely serious consideration would be given to refining the decision made.  Generally, this approach will be appropriate for sponsors with lower influence but higher importance (e.g. the Communications Director in our worked example).

 

Finally, there may well be some stakeholders (generally those with low influence and importance) where the best approach is to ‘control’ their input – to ensure that project resources are not diverted unnecessarily onto keeping them engaged in inputs, decisions and outputs:

 

Control

The stakeholder will be instructed to observe decisions taken.  Objections to or issues raised with a decision are unlikely to be given serious consideration.  Such stakeholders are likely to be (to some extent) quite literally under the control of the organisation (e.g. external suppliers, in our worked example). 

Stakeholder Participation Matrix

 

Clearly, the respective position of individuals on the Power Grid is unlikely to change significantly over time (during the project) but the approach taken to each may need to vary during the different stages of the project lifecycle.

 For example, it is unlikely that you would be giving your CEO daily updates on the progress of the project, but very likely you would need her specific approval and guidance at project initiation! Thus, the stakeholder approach outlined above needs to be adjusted to take into account the needs of both the stakeholder and the project itself during the project lifecycle. The table below illustrates how the stakeholder participation approach for ABC Co (our worked example) might vary over the life of the project:

Type of Participation

Stage in Cycle	Inform	Consult	Partnership	Control
Initiation		IT DirectorComms Director	Chief ExecutiveHR DirectorFinance Director
Planning	Comms Director	Chief ExecutiveLine ManagersIndividual Employees	HR DirectorFinance DirectorProcurement Director
Implementation	Chief Executive Individual Employees	Finance DirectorProcurement Director Line Managers	HR Director Comms Director	External Suppliers
Monitoring	Chief Executive Line ManagersIndividual EmployeesProcurement Director	Finance DirectorComms Director	HR Director	External Suppliers

 Note the interesting position of the Comms Director, who is consulted during project initiation, only informed through the planning stage but then actively engaged as a partner during implementation.

Portal best practices

A true services oriented architecture is designed to span different types of application servers, rather than relying on a single type of application server. To fully utilize this architecture, openness to resources developed in different programming environments and hosted on multiple application servers is paramount.

There are two approaches available to a portal when leveraging a distributed services oriented architecture, which spans multiple platforms. 

One approach places all portlets – modules that provide content to its calling portal container to be displayed on a portal page – within the same application server as the portal server. Services are then accessed remotely.  These remote services can include web services, or web services for remote portlets (WSRP), and are accessible by adhering to appropriate standards. 

An alternate approach places the portlets on disparate application servers, accessible as remote server-side services, in a distributed, HTTP-based architecture. This second approach creates an architecture which is more immediately scalable than models in which all portlets run within the same application server as the portal, while supporting multiple platforms. This second approach towards a distributed architecture also allows the portal to integrate more portlets, without requiring additional infrastructure at the portal server. 

Both approaches are open to portlets hosted on different platforms, when web services for remote portlets are implemented  The second approach goes beyond the dependency on the WSRP standard and adoption for remote access, when natively it supports simple web-based services – HTML, JSP and ASP pages – along with its own portlets to be hosted on different and remote platforms.

Beyond the traditional approach of presenting information from different systems as portlets appearing one beside the other, a comprehensive approach to integrating content, security, user information and search engines via Web services to be consumed by portlets is the best approach.

Portlet Standards
This architecture includes support for both Web Services for Remote Portlets (WSRP) and the Java Specification Request 168 (JSR 168) portlet standards. These standards are important because they free the Commonwealth from basing technology decisions on whether a vendor’s proprietary conventions prevail in the market. The Portal standards allow the Commonwealth to develop industry-standard portlets, and ensure that the investment can yield a return within any portal.

Implementations of WSRP are based on a Web Services Architecture, which allows portlets to run remotely from the application server hosting the portal.  The Java JSR 168 specification allows for portlets created for one portal solution, to execute within a non-native hosted Java based portal container.  This architecture helps ensure that the portal remains open to resources hosted on a wide range of application servers, and unaffected by faults in any one portlet. This architecture also supports a wide range of other integration components that run as Web Services, for indexing content, importing security information, federating searches and profiling users.

Architectural Styles

An architectural style in software consists of a few key features and rules for combining those features so that architectural integrity is preserved.An architectural software style is determined by the following:set of component types (e.g., data repository, a process, a procedure) that perform some function at runtime  topological layout of these components indicating their runtime interrelationships set of semantic constraints (for example, a data repository is not allowed to change the values stored in it) set of connectors (e.g., subroutine call, remote procedure call, data streams, sockets) that mediate communication, coordination, or cooperation among components.

Data Centered Architectures Data-Centered architectures have the goal of achieving the quality of integrability of data.The term Data-Centered Architectures refers to systems in which the access and update of a widely accessed data store is an apt description. At its heart, it is nothing more than a centralized data store that communicates with a number of clients. The means of communication (sometimes called the coordination model) distinguishes the two subtypes: repository (the one shown) and blackboard. A blackboard sends notification to subscribers when data of interest changes, and is thus active.

Data-centered styles are becoming increasingly important because they offer a structural solution to illegibility. Many systems, especially those built from preexisting components, are achieving data integration through the use of blackboard mechanisms. They have the advantage that the clients are relatively independent of each other, and the data store is independent of the clients.

Thus, this style is scalable: New clients can be easily added. It is also modifiable with respect to changing the functionality of any particular client because otherwise will not be affected. Coupling among clients will lessen this benefit but may occur to enhance performance.

Data-Flow architectures have the goal of achieving the qualities of reuse and modifiability.The data-bow style is characterized by viewing the system as a series of transformations on successive pieces of input data. Data enter the system and then flows through the components one at a time until they are assigned to some final destination (output or a data store).In the batch sequential style, processing steps, or components, are independent programs, and the assumption is that each step runs to completion before the next step starts. Each batch of data is transmitted as a whole between the steps.

The typical application for this style is classical data processing.

The Pipe-and-Filter style emphasizes the incremental transformation of data by successive components. This is a typical style in the UNIX family of operating systems.

Filters are stream transducers. They incrementally transform data (stream to stream), use little contextual information, and retain no state information between instantiations. Pipes are stateless and simply exist to move data between filters.

Both pipes and alters are run non-deterministically until no more computations or transmissions are possible. Constraints on the pipe-and-alter style indicate the ways in which pipes and alters can be joined.

A pipe has a source end that can only be connected to a filter’s output port and a sink end that can only be connected to a alter’s input port.

Pipe-and-filter systems, like all other styles, have a number of advantages and disadvantages.

Their advantages principally flow from their simplicity-the limited ways in which they can interact with their environment.

This simplicity means that a pipe-and-filter system’s function is no more and no less than the composition of the functions of its primitives.

There are no complex component interactions to manage.

Pipe-and-filter systems advantages:The pipe-and-filter style simplifies system maintenance and enhances reuse for the same reason-filters stand alone, and we can treat them as black boxes.Both pipes and filters can be hierarchically composed: Any combination of filters, connected by pipes, can be packaged and appear to the external world as a filter.

Because a filter can process its input in isolation from the rest of the system, a pipe-and-filter system is easily made parallel or distributed, providing opportunities for enhancing a system’s performance without modifying it.

Pipe-and-filter systems also suffer from some disadvantages.There is no way for filters to cooperatively interact to solve a problem.Performance in such a system is frequently poor for several reasons, all of which stem from the isolation of functionality that makes pipes and alters so modifiable; these reasons are listed below:

Filters typically force the lowest common denominator of data representation (such as an ASCII stream). lf the input stream needs to be transformed into tokens, every filter pays this parsing/unparsing overhead.

If a alter cannot produce its output until it has received all of its input, it will require an input buffer of unlimited size. A sort filter is an example of a filter that suffers from this problem. lf bounded buffers are used, the system could deadlock.

Each filter operates as a separate process or procedure call, thus incurring some overhead each time it is invoked.

Virtual Machine Architecture Virtual Machine architectures have the goal of achieving the quality of portability. Virtual machines are software styles that simulate some functionality that is not native to the hardware and/or software on which it is implemented.This can be useful in a number of ways:It can allow one to simulate (and test) platforms that have not yet been built (such as new hardware), and it can simulate “disaster” modes (as is common in flight simulators and safety-critical systems) that would be too complex, costly, or dangerous to test with the real system.

Common examples of virtual machines are interpreters, rule-based systems, syntactic shells, and command language processors.

Interpretation of a particular module via a Virtual Machine may be seen as follows:

• the interpretation engine selects an instruction from the module being interpreted;
• based on the instruction, the engine updates the virtual machine internal state;
• the process above is repeated;

Executing a module via a virtual machine adds flexibility through the ability to interrupt and query the program and introduce modifications at runtime, but there is a performance cost because of the additional computation involved in execution.

Call-and-Return Architectures Call-and-Return architectures have the goal of achieving the qualities of modifiability and solvability.Call-and-Return architectures have been the dominant architectural style in large software systems for the past 30 years.However, within this style a number of substyles, each of which has interesting features, have emerged.

Main-Program-and-Subroutine architectures is the classical programming paradigm. The goal is to decompose a program into smaller pieces to help achieve modifiability.A program is decomposed hierarchically. There is typically a single thread of control and each component in the hierarchy gets this control (optionally along with some data) from its parent and passes it along to its children.

 

Remote procedure call systems are main-program-and-subroutine systems that are decomposed into parts that live on computers connected via a network.The goal is to increase performance by distributing the computations and taking advantage of multiple processors. In remote procedure call systems, the actual assignment of parts to processors is deferred until runtime, meaning that the assignment is easily changed to accommodate performance tuning. In fact, except that subroutine calls may take longer to accomplish if it is invoking a function on a remote machine, a remote procedure call is indistinguishable from standard main program and subroutine systems. Object-oriented or abstract data type systems are the modern version of call-and-return architectures.The object-oriented paradigm, like the abstract data type paradigm from which it evolved, emphasizes the bundling of data and methods to manipulate and access that data (Public Interface).The object abstractions form components that provide black-box services and other components that request those services. The goal is to achieve the quality of modifiability.

This bundle is an encapsulation that hides its internal secrets from its environment. Access to the object is allowed only through provided operations, typically known as methods, which are constrained forms of procedure calls. This encapsulation promotes reuse and modifiability, principally because it promotes separation of concerns:

The user of a service need not know, and should not know, anything about how that service is implemented.

Layered systems are ones in which components are assigned to layers to control intercomponent interaction. In the pure version of this architecture, each level communicates only with its immediate neighbours. The goal is to achieve the qualities of modifiability and, usually, portability. The lowest layer provides some core functionality, such as hardware, or an operating system kernel. Each successive layer is built on its predecessor, hiding the lower layer and providing some services that the upper layers make use of. Independent Component ArchitecturesIndependent component architectures consist of a number of independent processes or objects that communicate through messages.All of these architectures have the goal of achieving modifiability by decoupling various portions of the computations. They send data to each other but typically do not directly control each other.
The messages may be passed to· named participants (Communicating Processes style);

· unnamed participants using the publish/subscribe paradigm (Event Style) .

Event systems are a substyle in which control is part of the model. Individual components announce data that they wish to share (publish) with their environment − a set of unnamed components.These other components may register an interest in this class of data (subscribe). If they do so, when the data appears, they are invoked and receive the data.Typically, event systems make use of a message manager that manages communication among the components, invoking a component (thus controlling it) when a message arrives for it. In this publish/subscribe paradigm, a message manager may or may not control the components to which it forwards messages.

Components register types of information that they are willing to provide and that they wish to receive.

They then publish information by sending it to the message manager, which forwards the message, or in some cases an object reference, to all interested participants.

This paradigm is important because it decouples component implementations from knowing each others’ names and locations. As mentioned, it may involve decoupling control as well, which means that components can run in parallel, only interacting through an exchange of data when they so choose. This decoupling eases component integration

Besides event systems, the other substyle of independent components is the communicating processes style. These are the classic multiprocess systems.

Of these, client-server is a well-known subtype. The goal is to achieve the quality of scalability.

A server exists to serve data to one or more clients, which are typically located across a network. The client originates a call to the server, which works, synchronously or asynchronously, to service the client’s request.

If the server works synchronously, it returns control to the client at the same time that it returns data. If the server works asynchronously, it returns only data to the client (which has its own thread of control).

Heterogeneous StylesSystems are seldom built from a single style, and we say that such systems are heterogeneous.

There are three kinds of heterogeneity, they are as follows.

Locationally heterogeneous means that a drawing of its runtime structures will reveal patterns of different styles in different areas.For example, some branches of a Main-Program-and-Subroutines system might have a shared data repository (i.e. a database).Hierarchically Heterogeneous means that a component of one style, when decomposed, is structured according to the rules of a different styleFor example, an end-user interface sub-system might be built using Event System architectural style, while all other sub-systems − using Layered Architecture.

Simultaneously Heterogeneous means that any of several styles may well be apt descriptions of the system.This last form of heterogeneity recognizes that styles do not partition software architectures into non-overlapping, clean categories. You may have noticed this already. The data-centered style at the beginning of this discussion was composed of thread-independent clients, much like an independent component architecture.The layers in a layered system may comprise objects or independent components or even subroutines in a main-program-and-subroutines system. The components in a pipe-and-filter system are usually implemented as processes that operate independently, waiting until input is at their ports, again, this is similar to independent component systems whose order of execution is predetermined.

Why database indexing does not always work?

There is a misconception in application development community that performance related database issues can be attributed to lack of indexes.  This thinking leads to creation of indexes whether they are required or not. A comprehensive database performance management strategy is required to address performance related issues.

Creating more indexes than necessary or overindexation leads to performance problems. Yes, rather than solving the issue, having more indexes can slow your application. Some pointers to consider…

• Indexes on small tables  with less than 1000 rows add no value
• Indexes are useful when searches are for keys which belong to a small minority.
• Concatenated indexes should be concatenated from the most selective to the least selective column
•  Indexes on single columns which also appear as the first column in a concatenated index are redundant. Databases engines can use the concatenated index when only the first columns in the index appears in the search condition. 
• When more than 10% of rows are returned, a full table scan is often as fast if not faster than an index search.

Project Post-Mortem

The purpose of the Post Mortem is to describe in detail the specific activities that were most effective and those that need adjustments prior to the next project.  The goal is to inform future project teams of the obstacles encountered during this project. Post Mortem will focus upon identifying the following:

• Processes which need adjustment
• Most effective Processes
• Providing Action items

Postmortem Questions

These questions are meant to generate discussion about what went well, what the team struggled with during the milestone just reached, and what the team would do differently moving toward the next milestone.

It helps to distribute these questions to the team before the postmortem meeting, to give team members a chance to think through and document their responses beforehand.

Planning

Were the group goals clear to you?

Were the marketing goals clear to you?

Were the development goals clear to you?

How complete do you think the planning was before the actual commencement of work?

How could planning be improved?

What recommendations would you make for the planning process for the next release?

 

Resources

How can we improve our methods of resource planning?

Were there enough resources assigned to the project, given the schedule constraints?

What could have been done to prevent resource overload?

Do you think resources were managed effectively once the project started?

 

Project Management/Scheduling

Was the schedule realistic?

Was the schedule detailed enough?

Looking over the schedule, which tasks could you have estimated better and how?

Did having a series of milestones help in making and monitoring the schedule?

What were the biggest obstacles to meeting the scheduled dates?

How was project progress measured? Was this method adequate? How could it be improved?

Was contingency planning apparent? How can we improve our contingency planning for the next release?

How could scheduling have been done better or been made more useful?

What would you change in developing future schedules?

How were changes managed late in the cycle?

Were the trade-offs between schedule and features handled well?

 

Development/Design/Specifications

Were there issues in the functional design and ownership?

Were there issues in the architectural design and ownership?

Were there issues involved in using components or with code sharing? How could this be done more effectively?

 

Test

Were there issues in test interaction?

Were there issues in test case design and coverage?

Were there enough testers?

Was the quality of the product we shipped acceptable?

Did we work well with all of the testers?

Communication

Was communication in your group handled efficiently/effectively?

Was communication between groups handled efficiently/effectively?

Was program management effective in disseminating information?

Was program management effective in resolving issues?

Was the e-mail alias usage effective? How could the aliases be better set up to improve communication?

Were the status meetings effective?

Was communication with the external groups (component suppliers, content suppliers, OEMs, support, international) effective?

Team/Organization

Did you understand who was on the team and what each member was responsible for?

Were the roles of the different groups (development, test, user education, program management, marketing) clear to you?

What would you do to alter the organization to more effectively put out the product? What functional changes would you make? What project team organization changes would you make?

Do you think the different groups fulfilled their roles?

What was deficient in your group? Other groups?

Did you have all the information you needed to do your job? If not, were you able to obtain the information?

Did you think the team worked together well?

 

Product

In retrospect, could the work of your group been done better? How?

What needs to happen so your group can avoid problems in the future?

Are you satisfied with the product you shipped? If not, why?

What would you do to improve the process of creating the product?

 

Management (Group and Program Managers)

Did your manager help you do your job? Explain.

Did you view management’s role as useful?

Were management decisions communicated to the team? Did you understand how decisions were made?

Were external dependencies managed effectively?

 

Tools and Practices

What improvements do you recommend for tracking bugs that will make the process more effective for use during development of the next release?

What improvements do you recommend for document and code source control?

What comments do you have about the build process and the compilers?

What comments do you have about the coding standards?

What other tools do you need?

What other improvements do you need to make on your existing tools?

General

What three things (in order of importance) went well?

What three things (in order of importance) need improvement? Please offer suggestions for methods of improvement.

What other issues would you like to raise?

Design patterns and WDK Programming – Part 1

Currently, I am working on creating best practices for WDK programming. As a part of this, I am planning on introducing design patterns in WDK Programming (where applicable) to make WDK Programming more predictable. Through a series of posts, I will describe in detail using a WDK customization how using design patterns help in achieving efficiencies.  I have identifed following design patterns from GOF. Stay tuned..

Creational Patterns

 1.       Abstract Factory – Provide an interface for creating families of related or dependent objects without specifying their concrete classes (Kit) 

 2.       Builder – Separate the construction of a complex object from its representation so that the same construction process can create different representations. 

 3.       Factory Method – Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. (Virtual Constructor)   

4.       Prototype – Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

  5.       Singleton – Ensure a class has only on instance, and provide a global point of access to it. 

Structural Patterns

 6.       Adapter – Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. (Wrapper) Class adapter: Object Adapter:  

 7.       Bridge – Decouple an abstraction from its implementation so that the two can vary independently. (Handle) 

 8.       Composite – Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and composition of objects uniformly.  

9.       Decorator – Attach additional responsibilities to an object dynamically. Decorator provides a flexibility to sub classing for extending functionality. (Wrapper).  

 10.   Façade – Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use. 

 11.   Flyweight – Use sharing to support large numbers of fine-grained objects efficiently. 

 12.   Proxy – Provide a surrogate or placeholder for another object to control access to it. (Surrogate) 

Behavioral Patterns

 13.   Chain of Responsibility – Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle request. Chain the receiving objects and pass the requests along the chain until an object handles it.  

 14.   Command – Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. (Action, Transaction) Command de-couples the object that invokes the operation from the one that knows how to perform it.  

 15.   Interpreter – Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. Useful in designing language related applications and compilers. 

16.   Iterator - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. (Cursor)  

17.   Mediator – Define an object that encapsulates how a set of objects interacts.  Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. 

18.   Memento – Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later. (Token) Example – supporting undo operations.

 A memento is an object that stores a snapshot of the internal state of another object.  

19.   Observer – Define a one-to-many dependency between objects so that when one-object changes state, all its dependents are notified and updated automatically. (Dependents, Publish-Subscribe)  

20.   State – Allow an object to alter its behavior when its internal state changes. The object will appear to change its classes.  

21.   Strategy – Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets algorithm vary independently from clients that use it. (Policy)    

22.   Template Method – Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm. This pattern is so fundamental that it is found in almost every abstract class.  

23.   Visitor – Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.