Solution Architect Boot Camp

You have indicated that you would be most interested in the Solution Architect Boot Camp.  If this is a new field for you, you may wish to preceed this with the Information Architect Boot Camp, the fundamentals course.

Web Application Architecture

This article places focus on architecture tips for you and your web applications. Today’s organizations are either using a combination bricks and mortar and web interface with customers, or they are likely creating in house web applications that never leave their firewalls. In either case, architecture is just as important as ever.

Read the rest…

Here is an example of an Solution Architecture Layered Diagram.

Notice the “category” of components or parts of the layer noted on the right side. Each square or box here represents a technology or methodology in use at this organization.

These components are all a part of the software process at this organization.

softwarearchitecturesample

Short-Term

• Enhances reliability
• Reduces hardware acquisition costs
• Leverages existing development skills
• Accelerates movement to standards-based server and application consolidation
• Provides a data bridge between incompatible technologies

Long-Term

• Provides the ability to build composite applications
• Creates a self-healing infrastructure that reduces management costs
• Provides truly real-time decision-making applications
• Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners

Business Value

• Ability to more quickly meet customer demands
• Lower costs associated with the acquisition and maintenance of technology
• Management of business functionality closer to the business units
• Leverages existing investments in technology
• Reduces reliance on expensive custom development

SOA:

Allows applications to be broken into services that can be accessed by other applications and systems to create powerful composite applications based on the functionality available in applications across the enterprise.

Benefits of an Event-Driven Architecture

Short-Term

• Allows for pro-active problem solving
• Better addresses customer needs without resorting to one-off customization by helping drive dynamic processes

Long-Term

• Improves customer loyalty and satisfaction
• More visibility into business health through near real-time organizational dashboards

Business Value
  • Provides the best products and/or services to customers and partners
  • Competitive advantage over slower-moving competitors
  • Greater visibility into enterprise status and issues
Event-driven Architecture:

Provides a fundamental mechanism to capture key changes in business needs and technical implementation. These changes can then be used to effect instantaneous changes to business processes and the underlying systems that support them.

Client Server Pattern

Patterns have been around for a long time, but they became common place when the world turned to Client Server as it’s golden spike. Here is a common pattern which includes three clients, a business object server, a database server and a web server. One might call this an “N-Client” pattern.

clientserverpattern

Successful Information Architecture

A successful Enterprise Information Architecture (EIA) starts from the perspective of the Business Strategy, and a view of business goals and strategy. We consult in the areas of Enterprise Information Architecture Design, as well as with the necessary policies, procedures and processes required to ensure human interaction is optimized. We are sensitive to information needs, behaviours and vocabularies of the various users who must interact with the architecture.

SuccessfulEnterpriseInformationArchitecture

The Enterprise Information Architecture is the center most intersection of this diagram.

This is where all high-level planning activities and artifacts are created.

The three domains – Business, Users and Organization contribute data and context to the activities.

* Users: (who they are, what their information-seeking behaviors and needs are)
* Content: (volume, formats, metadata, structure, organization)
* Context: (business model, business value, politics, culture, resources and resource constraints)

Sample Solution Architecture

Here is a Solution Architecture 1 page model. Here is an example of a Solution Architecture Diagram with operational and external environment components. Notice the “categories” or groupings of components and the method in which they are layered on the diagrams.

These components are all a part of the software process at this organization

SampleSolutionArchitectureDiagram

Solution Architecture Quality Checklist 

  • Is the overall program organization clear, including a good architectural overview and justification?
  • Are modules well-defined including their functionality and interfaces to other modules?
  • Are all the functions that are listed in the requirements covered sensibly,
    neither by too many nor too few modules?
  • Are all major data structures described and justified?
  • Are major data structures hidden with access functions?
  • Is the database organization and content specified?
  • Are all key algorithms described and justified?
  • Are all major objects described and justified?
  • Is the user interface modularized so that changes in it won’t affect the rest of the program?
  • Is a strategy for handling user input described?
  • Are key aspects of the user interface defined?
  • Are memory use estimates and a strategy for memory management described and justified?
  • Does the architecture set space and speed budgets for each module?
  • Is a strategy for handling strings described, and are character-string-storage estimates included?
  • Is a strategy for handling I/O described and justified?
  • Is a coherent error-handling strategy included?
  • Are error messages managed as a set to present a clean user interface?
  • Is a level of robustness specified?
  • Are necessary buy vs. build decisions included?
  • Is the architecture designed to accommodate likely changes?
  • Is any part over- or under-architected?
  • Are the major system goals clearly stated?
  • Does the complete architecture hang together conceptually?
  • Is the top-level design independent of the machine and language that will be used to implement it?
  • Are motivations given for all major decisions?
  • Are programmers who will implement the system, comfortable with the architecture?
    Do they understand it and support it?
  • Mergers & acquisitions – Calling All Architect’s – We’ve Got a Merger & Acquisition

    What are your IT Project Priorities – do you have one of those “Yours, Mine & Ours” situations???

    What I mean is that when a business decides to buy another company, or merge with one, often there are multiple perspectives to project priorities. If one business arm decides they need a bigger sales force, and another wants to gain proficiencies in a manufacturing process, there may be conflicts. Add the fact that the IT area wants to streamline, yet add or upgrade technology infrastructure, we’re cooking up a recipe for missed expectations.

    The IT Architect needs to understand what the end goals are by the business when creating the architecture. If you want to read more on ensuring you understand the right messages and goals, why don’t you check out my information site – Mergers & Acquisitions and the Information Architect is an article that addresses this topic.

    It’s a sample exerpt from our eZine “The Architect Abstract”. Head to the site to sign up to get a copy every week, or view the sample articles to whet your appetite.

    Happy Architecting!
    Sharon