So what should your application GUI prototype patterns include? Promises were made to get into the speed lane, so fasten your seat belts:

To wizard or not -  my preference is not to try to use these in custom applications. If you are mimics some very common plug in and e-commerce software that many use on the internet – go for it. Typically, some smart developer will step forward and say “Hey – I build a wizard and people will love this. Often I see these moments of brilliance and say “huh?” or scratch my head. Often they start off simply, and can become very confusing as more or complete functionality is added.

I would also hazard the rule of thumb that if the wizard has any exit points or extensions, doesn’t do it. If the user can keep hitting next and it’s very obvious as to where they have arrived and have the ability to return without losing state, it might be ok. Most of the time it will be intuitive for the writer only, and very confusing to the user until they’ve learned it. They will have to learn about each new one when a new piece of functionality or a screen is added, as rarely can they be consistent.

Instead – use functions such as and icons to perform an activity or invoke a service. An example might be a search function, which everyone could learn and use to populate screen fields. Adding items to a list in the master-list scenario is another area in which the pattern could be used. An actor creates the master, selected an “add item” type button or function, a new screen pops up and the actor adds the information.

Navigation Bars - Above and Beyond: So where should the nav bars go? I won’t spend time on this one, but get people used to where they will appear and decide on context. I like a pattern where the top nav bars address the sections or categories within the application (major activities or perspectives) and the side bar (my preference is left), gives the user their available options for the page they are viewing. Make the options on the left standardized (buttons) and the top icons control major application functionality.

The pattern should include security options such as visibility. If the user can’t do it, they shouldn’t see it. When a user logs into the system, they should have a need for every icon across the top bar (otherwise it doesn’t appear), and they should be allowed to select each button on the left and they should navigate to another place.

Buttons Should be at a premium: – Your tailor should only use the minimum amount of buttons to close the garment – meaning be very frugal here. Decide which buttons your pattern will include and then insist on consistency. Choose SAVE or CLOSE or END. Choose CANCEL or EXIT and communicate their meaning and behaviour.

Other options include the whole ADD family – ADD, APPLY, CREATE, NEW – which one will you use? When we think of the good old crud matrix, we must create new things and use one button to do so on all panels. We can update items, and the most economical way is to hyperlink indicating the ability to update something rather than adding another button. If you must, choose UPDATE, CHANGE, or MAINTAIN, but not all.

What about the DELETE button? If you can, try an “X” or another icon beside the item to indicate the option to delete. Decide whether that will mean a logical or physical deletion and shout it from the roof tops. Try to make that consistent in your patterns.

Error messages are another area for patterns. There should be a global set for validation. My preference lies in documenting these once in a design document vs. every single use case, or separate design documents. If you are using a requirements management tool that easily enables you to use business rules, the error messages should be tied to one and documented within the use case. The gory details can live in the document about how they work and their outcome.

Summary and Details: - Storage might be cheap, but real estate is at a premium. Your patterns for GUI design should include the bare minimum and ways to “explode” or “expand” to detail pages. Create one pattern for doing this for detailed lists, documents, screens with many update fields, and the user will be happy they don’t need to wade through it all before getting the information that they came for.

A mind teaser: Patterns and services go hand in hand, and if you have decided on a Service Oriented Architecture, and are underway, you’ll want to create patterns and templates for design so that users can invoke the services they require, if they are to be controlled by them. We’ll save that for later, and hope that today’s speed lane will at minimum give you food for thought, or improve on a great idea you already had!

Prototyping is an approach which is used within a Systems Development Lifecycle.  It can be a key exploration technique for some aspect of the system, or an approach used during the design process and requirement collection phases.

Prototyping is an activity typically used in one of two ways: as an approach or technique when it is meant to be throw-away for a proof-of-concept, technology comparison, or to validate new technology.  It can also be used from a methodology standpoint – at the core of system evolution when it is used as part of an iterative process to develop a system.

Prototypes may start out as horizontal or conceptual prototypes to prove the concept, the project is improved, and they may be built upon to demonstrate and build the user interface, and further explored by building vertical prototypes which may become fully functional.

Prototypes are models on which the final system may be patterned.  As soon as the first prototype is put before users (and often even before that), changes will be requested. (You can be almost certain of this one!) These changes should be managed with formal change management processes.

Some Examples and Uses of Prototypes:

Horizontal or Conceptual prototypes – are built and used at the conceptual level, with a wide-brush perspective. They are commonly used for user interface design testing, and they are typically kick off or begin the iterative process when they are not being thrown away.

Vertical prototypes are typically used during evolutionary project phases  – they explore deeply one area, domain or technology within the system

Technical prototypes are typically experimental or used during exploratory phases of the project.  They are typically used for proof-of-concept, and are performed on difficult or unproven components of the system.

Executable prototypes are those built during one or more iterations which address all critical requirements identified in the vision document and expose the top technical risks.

When Should You Use Prototyping Techniques?

Prototyping is a key tactic for reducing risk on your projects.  The cost of taking time to prototyping is far less than the cost of the fault occurring in later stages, or worse, the project failing entirely. A prototype can normally be performed using existing resources, or demo copies of new software. Full scale investment can normally be avoided if risk is deemed too high.

Prototype findings are very useful if full scale investment is the next step in the lifecycle of the project. Abandoning the project usually has no operational, competitive or legislative consequences.

Each risk should be assessed appropriately, risk reduction should be computed, and then compared with the cost of prototyping. Prototyping should be taken seriously, and with full efforts on a level playing field for judgments to be fair.

Prototypes should also be used to initiate and then subsequently validate various phases of iteratively designed systems. As each phase and prototype are built, users can verify they are getting what they want and project-end surprises can be minimized.

My biggest tip for prototypes?  Use the technology that you will use on the project for the prototype.  You can get false readings by using what you might deem as suitable available substitutes.

The biggest lesson I ever learned in doing a conceptual prototype was by using PowerBuilder to demonstrate both functionality and UI for a system that was to be built using Visual Basic.  At the time, Microsoft did not nearly have the needed functionality available, and decisions were made based on the quickest prototyping method. Implementation fell short because the technology could not deliver.

This article will focus on the need to include SOA within your EA.

SOA – A Major Building Block in Enterprise Architecture

Service Oriented Architecture is not meant as a new way to define Enterprise Architecture, but it definitely needs to be a major focus of both the application architecture and technology architectures.

When building our Enterprise Architectures, many organization fall into the trap of believing that they need to create models, principles, guidelines and standards on every part of their environment. This is usually why it is never completed, the projects are shelved and budgets run dry.

Successful organizations create strategies to build their Enterprise Architectures in an iterative manner, focusing on the framework and basic components first, and then moving on to add critical models and detail sections of the architectures piece by piece as IT initiatives dictate.

SOA should be viewed as a “sub-architecture” of the Enterprise Architecture, one which should be a primary and early focus. Many organizations will have components of architecture for connection and messaging capabitilities needed for SOA. These should be heavily documented in great detail, and the EA strategy should include a communication strategy that shouts from the rooftops that this architecture is available and ready for prime-time. Development teams should consider this architecture first when deciding on methods for their current projects.

SOA using web services will allow us to support today’s flexible needs of business. Our architectures should include, whether bought or assembled, most of the services we will need for our Enterprise Architecture. As new business initiative arise, we add value by reusing existing services that we have proven to be effective, and building or developing new services that give our organizations some type of competitive edge or fill our unique business needs.

Our enterprise archiecture, built within the confines of one or a few selected methodologies and framework will include views, abstractions and models. The basic components of the SOA infrastructure are paramount to our successes and must be modeled in detail in order for us to encourage the use of and support applications that will be built to give our business departments the edge.

Information and organizational technology requirements don’t really differ much between organizations. We all need customer, contact, accounting, financial, purchasing, human resources, and security solutions, just to name a few. Services and components will eventually be available to meet all of these needs in a variety of ways. We need to architect our systems and environments in such a way that we will be able to use these generic types of point solutions.

The uniqueness or competitive needs of our organizations and our business architectures will beg us to use solutions such as SOA to focus on the development needed, rather than the plumbing. We’ve all heard SOA is the next silver bullet, but there is work involved in accepting and including it in our architectures. The next models you build should embrace these thoughts and models, components and services to support this direction should be high up on your “to-do” list of models to be built.

Architect Boot Camp training was designed to help organizations train their own staff, or to help those in IT who have an affinity towards high end design & IT Strategy, but want to hone or learn Architect Methods, Process and Approach.  The objective is to deliver the theory, while using real life scenarios and then practice through case studies and exercises.

This fall our IT Architect Boot Camp workshop is now full, and we have but one spot left in our Solution Architect Workshop.  We had to move to larger space to deliver the workshops, and I’m sure with the great mix of staff and experience, they’ll be a good experience for all attendees.

If we can’t find architects, we’ve got to grow our own.  We need to optimize our IT dollars, and now more than ever we need to make sure we’re building and designing the right things.  Just ask John Zachman – he’ll tell you that Architecture is the ONLY way we can improve our success rate.  Only three days to go until the start of this first public offering this fall, so this blog entry will have to be short.

By the beginning of November, there will be several more architects ready to provide value to their organizations.  We must applaud organizations who believe that investments in their people are good ones, and won’t be impacted by rough economic times.

Happy Architecting

I’m emerging from the haze of planning for my upcoming Architect Boot Camp classes.  My focus is editing my book, and between questions about “which course do I take” and “am I suited to be an architect”, I figured I’d write a series of posts related to the Architect’s Role.

The Architect’s Role

Problems are well less defined for an architect and they must spend the time to ensure that a context has been set before they go about assessing their problem.  They must ensure that the scope and the boundaries of the problem are very well defined.  The primary activity of the architect is to focus on the implications of the organizations objectives on technical choices. They must understand all of the over-arching dynamics and impacts in making such choices, as well as  leading a team of developers, integrators and implementers in the prescribed certain path.

The architect must contain and sustain an overall system view at all times while designing a solution.   The architect builds models of the problem and the solution space and must possess a very analytical and conceptual mind in order to visualize how the pieces may fit.   They must also have a strong ability to recognize patterns and apply things and concepts that they’ve known from their past when they approach new solutions.

Architects explore alternative approaches to almost every solution that is presented to them. They must view and take into account all of the different aspects within the organization such as people, process and technology, as well as technology, data, and applications when determining which approach they will take.  Architects spend a great deal of their time preparing documents, positions, presentations and diagrams, and they must be very strong in communication skills as well as their diagramming and documentation skills.

They must be very good modelers and able to adapt to varying levels of tools and be able to quickly pick up the skills required in order to use these tools readily.   Architects must have a strong business sense, and the ability to scale down or tailor up explanations of architecture to sponsors and stake holders as well as technical staff.  As you see, they must be able to describe things at very detailed levels for technology staff and implementers as well at the highest granular level for the business in order to demonstrate that they understand the business problem.

Success for an architect depends on skills and characteristics that are not typically emphasized in university curricula or on the job training.   An architect gains experience during their years within information technology.  They merge experience they may have gained from other careers and depends on their experience and their keen business sense in order to propose solutions.  They diagram &  document their solutions, and solve the largest and most complex technology problems for the organization.

More on the specific types of architects another day.

Have thoughts on this post?  Drop me a comment.

Happy Architecting!

I’ve been answering a few questions in email lately, so I thought I’d add the questions in this blog:

Question: Do you see a big benefit from the Solution Architect Workshop (SAB)?  What’s the difference between it and the Information Architect Boot Camp Workshop (IAB)?

Answer: The IAB will teach you what the role of IT Architect is, how the various types of IT Architects are interrelated, how they fit into the project lifecycles, and how to be an architect practitioner.  You’ll learn the skills you’ll need to play any architect role and the basic architecture methods and process.

The SAB will teach you how to do solution architecture, review many options and put together solutions.  You will learn the skills as well as the steps and process to complete various Solution Architect activities and artifacts.  It is the best course for someone in a project architect role, provided the attendee already knows how or has basic IT architect knowledge and skills

Question: Should I take both of these courses together?

Answer: As we go through the IAB workshop, we are going to practice the various IT Architect skills as they are taught.  We’ll work on a project throughout the three day workshop, and each successive step will build on the previous, so that we will have gone through a typical Architecture activity from start to finish after we have spent three days together.

In the following two days in the SAB, we’ll learn more about putting solutions together and about the various scenarios the Architect faces when asked to create or update the architecture.  We’ll use the existing Architect’s skills if the attendee is just joining us, or the skills just acquired in the IAB if they are continuing.  It is not necessary to take both, but if you are a self-taught architect, it would be beneficial to take both together, to learn some of the best of breed approaches, and practices.

Question: What happened to the 1 day Architect Boot Camps – The Introduction and the Executive Architect Boot camp?

Answer: These training sessions have been held multiple times in the last few years and demand wasn’t high following the catalog release.  These classes are targetted to be offered as an online offering in October.  There will be some self-study, and some instructor/participant interaction offered.  More information to follow – stay tuned!

Question: Where are the classes being held?

Answer: Currently we are only scheduled for Winnipeg in October.  We have plans to offer some classes in Phoenix Arizona in 2009, and are currently looking into demand in other large Canadian and U.S. centers.  Classes are always available in group settings.  If you are interested in booking a class for 6 participants or more at your workplace, contact us for more information – choose the option of “other” for location and fill out the rest of the form.

Question: Do you offer a coaching and mentoring service?

Answer: Our online coaching service will be released today – more information later on.  We do also offer Enterprise Architecture coaching through EAdirections.  For more information on either of these services, please contact us, or watch for our information blast coming out shortly.  If you would like to get on our list for notification, please fill out the contact request form.

If you have more questions, or have other architecture problems or questions you’d like answered, please give us your comments.

Happy Architecting