Xanadu

Project Success requires solving business problems by applying appropriate processes and software solutions.
Our knowledge at Xanadu begins with solid Object-Oriented fundamentals. We feel that software built today originates from excellent Object-Oriented skills. This is the starting point in building flexible, scalable, performant systems.
Solid Object-Oriented fundamentals are appended with the timely application of design patterns and best practices. Design patterns and best practices must be applied judiciously in order to maximize architecture understanding, simplicity, and reuse.

We offer a range of software architecture consulting services including:
Architectural Guidance
Enhancements, maintainance, scalability, and performance are typically not a problem until well into the product lifecycle. We provide the architectural guidance necessary in order to future-proof those solutions.
Strategic guidance: If you have decided that you need help on software architecture, but you are unclear how best to hire an architect, or how to use an architect on your team, we can advise you on the common organizational patterns and pitfalls.
Short-term guidance: Often development teams have strong implementation skills yet can benefit from the skills of an experienced architect to point the system in the right direction and help make key decisions that have long-term implications.

Early Stage Project Participation and Mentoring
The early stages of a project are the most critical. It sets the tone for team performance and stakeholder interaction. By participating during these early stages, we encourage solid application/infrastructure design, efficient team collaboration, and active end user participation. Sometimes team capabilities and/or development practices do not match project expectations. We share our efficient and agile processes, as well as our technical expertise so that software development teams maximize their productivity.
Skills transfer: Our architects work side-by-side with your development team, mentoring them during product development, and enabling your team to apply software architecture techniques autonomously during their next project.
Outsourcing: Use one of our architects when your team needs a “ringer” on the project.

Product Strategy
Our product strategy service can aid business leaders in thinking through early product concepts and defining clear business goals. The objective of this process is to ensure a stable base for the project requirements. All software requirements should support your specific business goals as well as provide you with a way to track your project success after launch.

Technology Consulting
Technology is always changing. So how will you know if you should build a custom solution or choose an out-of-the-box platform? Our years of experience can help you make that decision. Our knowledge of available platforms and modules can help you weigh short-term development costs versus long-term scalability needs to find the most cost-effective solution for the long haul. In some cases, we can even help you estimate the development cost to outsource the project.

We keep abreast of any new software concepts and theories, so that our solutions are not only applicable now, but easily enhanced and reused for the future.
Design Patterns
Design Patterns capture solutions that have been developed and evolved over time. They are simple and elegant solutions to specific problems in object-oriented software design. These are based on industry standards and business practices.
Service-Oriented Architecture (SOA)
Service-Oriented Architecture employs Web Services at the protocol level to build loosely coupled, plug-and-play software systems. It increases the reuse of disparate applications and legacy systems that may or may not be built on top of differing technology. It is a higher level of software development that takes advantage of existing systems, and easily allows new systems to be used by future systems.
Software Factory
A Software Factory is a development environment configured to support the rapid development of a specific type of application. Software Factories are just a logical next step in the continuing evolution of software development methods and practices. However, they promise to change the character of the software industry by introducing patterns of industrialization.

Typically, software architecture and development takes a many-pronged approach, culling ideas from disparate groups in separate meetings.

• system decomposition into structural elements, architectural components, subsystems, sub-assemblies, parts or "chunks", paying attention to development productivity, and flexibility or extensibility requirements associated with accommodating future functionality at a reasonable cost of change. A good decomposition satisfies the principle of loose coupling between the pieces, facilitated by clean interfaces, simplifying the problem by dividing it into reasonably independent pieces that can be tackled separately.
• Once broken down into pieces, ....
  - Do we have all the necessary pieces? The structure must support the functionality or services required of the system. The dynamic behavior of the system must be taken into account when designing the architecture. We must also have the necessary infrastructure to support these services.
  - Do the pieces fit together? This is a matter of interface and relationships between the pieces, . But good fit—that is fit that maintains system integrity—also has to do with whether the system, when composed of the pieces, has the right properties.
• cross-cutting concerns. We refer to broad-scoped qualities or properties of the system as cross-cutting concerns, because their impact is diffuse or systemic. It may be a matter of preferring not to isolate these concerns because the decomposition is being driven by other concerns, or it may be that no matter how you might “slice-and-dice” the system, multiple parts are going to have to collaborate to address these cross-cutting concerns. At any rate, to effectively address cross-cutting concerns, they must be approached first at a more broad-scoped level. Many system qualities (also known as non-functional requirements or system properties, often specified in service level agreements) are of this nature. To make the picture more complicated, the system qualities may conflict, so that trade-offs have to be made taking into account the relative priorities of the system qualities.