Guideline presentation

In more than one occasions I've publish internal documentation to provides a set of standards, guidelines and best practices for ensuring the consistent architecture and implementation of SOA across solutions.

To convey the key message across the document are organised as simple recommendations using Always, Endeavour, Consider, Avoid, Never. Each guideline is described as either good or bad practice. The following table illustrates the recommendation keywords and their intended meanings.

Keyword	Meaning
Always	The guideline should always be followed. Example: Always use Pascal casing for enterprise service and operations names.
Endeavour	The guideline should be followed in most cases; however there are few edge cases where it makes sense not to follow the guideline or it is impractical to expect developers to follow the guideline all the time. Example: Endeavour to follow the defined messaging patterns - sync, async, pub/sub, guaranteed delivery, etc.
Consider	The developer should consider the guideline as an option for solving a particular problem. Example: Consider using machine generated code.
Avoid	The guideline indicates something that is not generally a good practice. In most cases; developers are expected to follow the guideline. Example: Avoid comments that explain the obvious.
Never	The guideline indicates something the developer should almost never do. Example: Never use hardcode environment variables.

User retention is key

I believe the key ingredient for a successful mobile solution is user retention. The Zero to Product/Market Fit by Andrew Chen enforces this notion.

Modularisation of the integration services must support reuse across business domains

Integration solutions are means to provide capability exposed as integration services. These services are govern by metadata in the service registry to be use during design-time. Current usage of service metadata is only for binding service contract. An emerging trend is extrapolating service metadata for semantic service discovery in run-time.

Integration services can be extended to meet domain specific business requirements. However, project team needs to factor in service version changes.

Reusable services is the core driver for most of "IT cost reduction" and "lowering cost of ownership" initiatives.

Service-Oriented Architecture (SOA) lays the foundation for reuse of functions through interfaces (refactoring your legacy functions as web services is not SOA enablement).

Service registry must be the starting point in your design options study. Reuse integration services where necessary. Follow policy to obey the service contract and register dependencies against the service. Good Architect must comes up with at least two design options for every solution.

Common processing steps must be separated from the specific requirements of individual products.

User oriented functions must be separated from core business logic processing.

Decision support functions must be separated from transactional processing.

Integration Architecture must be current and relevant

The Integration Architecture is both a process and the result of the process. The process is iterative and the results are incremental. It will be regularly enhanced, updated and communicated.

Strong Integration Architecture continuity requires constant updates to adapt with Technology, IT trends, economic condition and objectives of the organisation.

Lessons from the past:

• Development and projects must update the Integration Architecture.
• There must be a process for the review and assessment of Integration Architecture.
• Audit by an external consultant on a regular basis.
• Utilise industry standards.
• Peer review must be a minimum assurance mechanism for any change to the Integration Architecture.
• Business and information system strategy must inform Integration Architecture.
• Industry trends must be considered.
• The Integration Architecture must capture both the future state and the current state models.
• Short-term tactical solutions versus long-term strategic solutions must be constantly re-examined.
• “Just enough architecture, just in time”: The Pareto principle must be embedded within the architecture development cycle, creating an understanding for the application of the 80/20 rule and culture.

What I learn from the Virgin Blue IT incident

There are three major factors determine the quality of a product: the people that
develop a software system, the technology that is employed by them, and the organisation of the process of development. In today's ever growing size and complexity of software projects, steering committee are investing into processes cope with the business stakeholders demand.

High cost project, late delivery, resource dependence are all symptoms of lacking processes.

The role of IT is to deliver software products to the business with minimal disruption. As a customer, I experienced the disastrous go-live of Navitaire New Skies ticketing system at Virgin Blue.

Here is a Release Management process I've developed for many clients to introduce "quality gates" into their SDLC. You may have notice that this process have emphasis on the Quality Assurance Testing phrase, from experience solid testing will yield good outcomes.

Roles and responsibilities

A good Consultant is a subject matter expert (SME) in his role.

So what makes a great Consultant? He who have two or more core competencies and is capable of performing different roles in appropriate situations.

Role	Responsibility
Solution & Enterprise Architects	Enterprise and business process architects responsible for defining and maintaining business solution design, enterprise architecture standards and principles
Project/Integration Lead	Integration lead (or the Integration Release and Resource Lead) manages the integration deliverables, resources and planning.
Integration COE	Consists of Integration Architects responsible for integration solution consulting and process governance assurance.
Design Owner	Design owner reports to Integration Release and Resource Lead and responsible for defining integration design as per requirements.
Development Owner	Development owner reports to Integration Release and Resource Lead and responsible for development of solution as per design requirements.
Environment Management & Integration Support	Environment management and integration support team is responsible for supporting the integration solution and environment (inc. production). This team also provides feedback in design processes.

Right angle bracket (>) in XML Specification

I like to close the discussion about the use of the right angle bracket (>) in XML document. Despite what the the claim "the greater than character is legal, but it is a good habit to replace it" by the w3schools, usage of the right angle bracket must be escaped! It clearly mentioned in the XML 1.0 Specifications:

The ampersand character (&) and the left angle bracket (<) must not appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. If they are needed elsewhere, they must be escaped using either numeric character references or the strings " & " and " < " respectively. The right angle bracket (>) may be represented using the string " > ", and must, for compatibility, be escaped using either " > " or a character reference when it appears in the string " ]]> " in content, when that string is not marking the end of a CDATA section.

In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup and does not include the CDATA-section-close delimiter, " ]]> ". In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, " ]]> ".

W3C Recommendation, Extensible Markup Language (XML) 1.0 (Fifth Edition), 26 November 2008

Drive: The surprising truth about what motivates us

Anyone who employs or manages staff in a creative enterprise would be mad to dismiss the ideas in this video.