1 Introduction

The author of PraXtice is passionate about architecture. We know it makes a difference! We also know that being an Architect is no easy task. The research tells us that most architects receive little to nothing in the way of training. That they are more likely to be sent on an empathetic listening course than receive any actual architecture training. We also know that Architects can only do their best work when they have developed confidence in their methods and tools. PraXtice was created to help with that.

2 The Crystal Clear Statement

Let us make one thing CRYSTAL CLEAR right from the outset. PraXtice is a tool for Architects. Applying PraXtice might improve your architecture practice, but it will NOT make you an Architect. There is more to architecture than any methodology can provide. It takes a long time, patience and a lot of effort to become an Architect. The PraXtice methodologies assume that you have served your apprenticeship and that you have the prerequisite knowledge, experience and access to the necessary resources and artefacts. If you think you can Google your way through this one; you are very much mistaken!

3 Let's Talk Methodology

Recent academic research shows that most Architects, while generally formally well educated, typically receive little practical architectural training. By and large Architects are left to fend for themselves and generally evolve their practice heuristically; that's by trial and error. While there is an immense body of knowledge available to Architects in academic and commercial publications and there are methodologies like TOGAF, these typically fail the practicing Architect on several counts.

Firstly, because Architecture is an emergent discipline, there's no consistent ontology; this makes the comparison, selection and integration of techniques into a methodology difficult. Then there's human capacity. Who has time to master a methodology while trying to do their job? To be frank, at 650+ pages TOGAF is bought more often than it's read. And many of the "certified" have confessed to studying it to pass the exam, but not actually practicing it! It's just too hard!

There's also a methodological elephant in the room. One thing that the academics agree on is that while there's lots of advice about WHAT Architects should do, you'll find precious little about HOW to do it. The wash-up is that we have smart folks, tasked with tackling tremendous complexity; usually on ridiculous time lines, trying hard to make a difference. It's not surprising that they end up playing it off the cuff!

With PraXtice we're out to slaughter all manner of mythical creatures, loitering elephants, sacred cows, man months and ugly truths to name a few. Our objective with PraXtice is to provide a practical methodology that you can start using today.

4 About PraXtice

The name PraXtice© is a synthesis of the words praxis, meaning application, as distinct from theory and practice, as in habitual or customary performance. Pronounced "practice", PraXtice is a research based methodology designed by Architects for Architects. The goal of PraXtice is not to simply tell you WHAT to do, but to show you HOW.

While PraXtice may align with other methodologies we make no claims of compatibility, alignment with or allegiance to any other methodology. PraXtice was developed with a single objective: to provide a practical research based methodology that Architects can use as a foundation for their day to day practice; that doesn't take weeks to read.

PraXtice is derived from Purpose Driven Architecture Practice (PDAP) a new design and action theory of architecture practice. PDAP offers a sociologically-centric alternative to the artefact centric discourse that dominates architecture. Using empirically substantiated knowledge, PDAP provides a framework that management and Architects can use to develop an effective architecture programme.

PraXtice comes in several editions, Free, Professional, Complete and Advanced. Each edition consists of a set of practice routines that address different perspectives (These are Zachman's perspectives, Owner, Planner, Designer, Builder, Subcontractor) of architecture. The Professional edition addresses the Designer, Builder and Subcontractor perspectives; ideal for solution architecture.

FreePraXtice is a subset of ProPraXtice that you can use to get going quickly, confident that when you adopt ProPraXtice you won't have wasted any effort.

The ComPraXtice edition focuses on the Planner and Owner perspectives with modules for different architecture segments. ComPraXtice provides tools and techniques for planning and governance.

AdPraXtice introduces a new architectural paradigm. It is the gold standard of PraXtice only available to qualified organizations. That's right, you can't just buy AdPraXtice. That's because we know that you don't implement architecture; you cultivate it!

5 Free PraXtice

The FreePraXtice edition is exactly that, free. It is provided at no expense or obligation, along with the FreePraXtice ArchiMate model. It's an application of the "Try before you buy" principle that reduces the cost of failure to near zero. That's about as RISK free as you can make it! If FreePraXtice doesn't work for you; it's okay, you didn't break the bank trying! However, FreePraXtice is provided strictly "as is" with absolutely no warranty, no guarantees and no claim of being fit for purpose. There's also no support whatsoever.

6 Starting with PraXtice

PraXtice is a model-centric methodology, by which we mean that models are the central artefacts of the methodology not paper documents. PraXtice is predicated on the concept of "working in the model". The modeling notation we use is ArchiMate. ArchiMate is owned by the Open Group and supported by, SparX Enterprise Architect, BIZZdesign Architect and others. But, we'll be using the Archi tool because it's free! However, we're sure that when you realize Archi's value and the time it saves you, you'll want to donate.
https://www.archimatetool.com/donate

Modeling can be a bit intimidating if you're not familiar with it. But, PraXtice makes it easy!

First time using ArchiMate, please read our ArchiMate Quick Start.

7 The Truth about Documentation

One purpose of solution architecture is to communicate a design. Traditionally this has been done with paper documents, often Microsoft Word documents and Visio diagrams. There's an ugly truth about documentation that PraXtice gets out of the way right up front. We've been using this approach for thirty years and it doesn't work. You can't write them, nobody reads them. In fact they are often unreadable and they're out of date before they've finished printing. Not to mention that versions proliferate like rabbits! But what's worse, is their content can't be validated. You can put any nonsense you like in a document or diagram. There are no standards and no constraints. Just imagine if engineers operated like that!

This lack of rigor has a detrimental effect on architecture and relations with the business. Pity the poor manager who's asked to sign off on a hundred page architecture document. Do you really think that signature means anything? Poor documents contribute, more than a little, to the perception that architecture is time consuming, expensive and ineffectual. Architects can spend so much time on documentation that they don't actually have time for architecture; it just kind of emerges as a by-product. That's hardly ideal for a discipline that's supposed to bring everything together.

The PraXtice folk know that you get this, but we also understand that many organizations are stuck in a template paradigm that's not easily changed. And so in line with our principle of "only fighting battles that you can win", we suggest that you stick with whatever documents the organization is comfortable with and paste PraXtice artefacts into them as needed. But, start telling everyone right now how much better modeling is for everyone!

8 PraXtice Overview

The FreePraXtice edition produces a model with a set of business, system, solution and technology views. Everything you need to define a solution.

While PraXtice proscribes a minimal set of views you are not restricted to them and we encourage you to develop additional views as needed. Most people would say good luck at this point. But the PraXtice folks don't believe in luck, we believe in method, the importance of the Architect and architecture as a craft.

9 Good PraXtice

First a word about PraXtice, the model should be accessible at all times so that you can capture EVERY detail as it is discovered. So, when someone says "did you know such and such"; you can quickly update the model. This is what we call "working in the model". Typically, it's very fast and really easy; something that's never the case with a document!

Two principles are the foundation of PraXtice: Rigor and Traceability. We apply these to modeling with two simple instructions.

Rigor: Leave Nothing Out
Regardless of how insignificant a fact might seem, record it in the model as you discover it. By working in the model you won't waste time hunting for details you discarded because you didn't realize their significance.

Traceability: Make Nothing Up
Never make anything up! If it's in your model then you must be able to point to it in the real world. Assumption is the mother of all … well you know! If you are unsure then color the element red (reserved for RISK in PraXtice) and attach a Note. The model must be "the best version of the truth" we have at all times.


Here's an example of the principles in action. Imagine you're reading a foundational document; a Business Requirements document for example. You come across the following statement:

For each entity or relationship you add an element or connector (relationship) to your view.

Everything below is derived from this statement. Nothing is made up and nothing is left out. We know what we know; this is the best version of the truth that we can get from this statement. It will turn out not to be the absolute truth. But at the moment, this is the best version we can get and what's more we can trace it to "a source of truth". The view is rigorous and traceable. We can have confidence in our artefact.

10 Let's Get Started

There! In four pages we've given you an introduction, some guiding principles and an example. See how concise FreePraXtice is? Now download the FreePraXtice Model and install Archi (also free, but not ours). If you already have a tool you can import the FreePraXtice Model or build your own. See PraXtice website for links. The FreePraXtice Model is only available in Archi format. Now let's get started on your first PraXtice model!

11 Architecture Vision

The Architecture Vision is the foundation artefact for FreePraXtice. It records what the solution should do and how that brings value to the business. So, let's create one.

11.1 Method

The Architecture Vision is developed by the Architect and the project Sponsor. It has two sections that describe the solution's purpose and how the solution adds value to the business:

• Each section should be a single paragraph
• Each statement should be unambiguous and verifiable
• Statements should be ordered by priority
• Create a single Architecture Vision slide
• Append the slide to the front of ALL project presentations
• Distribute, quote and display the Architecture Vision widely

If a section cannot be satisfied in a single paragraph then you do not have a well-formed Architecture Vision. This is a MAJOR RISK!

11.2 Validation

The Architecture Vision is well-formed when:

• Both sections are complete
• The Sponsor and the Architect verify that the vision is aligned with business expectations
• The team agrees that the vision is unambiguous and verifiable
• The team agrees that the vision is doable

DO NOT PROCEED until the Architecture Vision is validated.

11.3 Architect's Notes

An Architecture Vision is the beginning of the formalization of a concept into an architecture. The Purpose Section sets a nascent scope while the Value Section contains the geneses of the "design constraints". Models begin by representing the high level perspectives of Owner and Planner. They develop to include the Designer and Builder perspectives. Ultimately models provide the source of truth for all perspectives.

11.4 Example

11.4.1 Purpose Section

The solution will allow an operator to see all the client's transactions (unambiguous and verifiable primary objective). The transactions will be ordered by date most recent first (unambiguous and verifiable) and presented in an abbreviated format (somewhat ambiguous statement needs clarification, but secondary).

11.4.2 Value Section

The solution increases the Customer Service Representatives' opportunities for cross selling (unambiguous and verifiable).

12 Establish Your PraXtice Model

The FreePraXtice Model is a set of ArchiMate views that refine the Architecture Vision. Before we can do this the model must be primed with its primary elements.

12.1 Architecture Notation

PraXtice assumes a rudimentary knowledge of ArchiMate notation and exposure to the Archi tool. This paper does not explain ArchiMate terms or how to use Archi. More information is available on the PraXtice website. But chill, it's not hard and the data tells us that Architects are pretty smart!

12.2 Principles of PraXtice Modeling

These are the principles of PraXtice modeling:

1. Work in the model
2. Use primary sources of truth
3. Leave nothing out, add nothing in
4. Assume nothing
5. Infer, verify and record
6. Unverified components MUST be Noted
7. If it's a RISK color it RED
8. Verify before you validate
9. If it's not validated it's not fit for purpose

12.3 Method

1. Gather ALL the documents that describe the environment in which the Architecture Vision is set
2. Copy the latest version of the FreePraXtice Model from this website
   
   Download FreePraXtice Archimate model
   
   
3. Record the Architecture Vision on the Model's Main tab
4. Open Views - PraXtice Method Layer - Scratchpad
5. Set the Viewpoint in the Main pane to None
6. Read through the primary source documents dropping elements onto the Scratchpad as they are discovered. (See section 12.7 Scanning Example). Don't worry about being tidy (See figure 2). The purpose of this task is to prime the model. The model will become increasingly accurate as the architecture develops

METHOD NOTE: Not all elements will be discovered nor can all relationships be resolved by this task

METHOD NOTE: Do not be concerned if your Scratchpad is a disorganized mess, they typically are. You will NOT be sharing the Scratchpad it is your work space

METHOD NOTE: The elements you add to the model will appear in the Business, Application and Technology folders underneath the Examples folders. You should only use these elements from now on. The Examples may be deleted when they are no longer useful

7. When ALL primary sources have been recorded this task is complete

The PraXtice model is now the best version of the truth you have. It MUST ALWAYS be up to date and well-formed. Models are dynamic and change frequently; often radically in the early stages of design.

12.4 Validation

A Scratchpad is well-formed when:

• All components documented in primary sources are recorded in the model
• The model contains all inferred elements
• All elements have been verified by another Architect familiar with the Architecture Vision

12.5 Architect's Notes

Sets of elements may be grouped by function. For example, multiple banks might be grouped and presented as a "Set" element - Depositing Banks.

12.6 Scratchpad Example

12.7 Scanning Example

Imagine you are scanning a source and come across the statement:
Each noun in this statement is an element. So we have: The Avion Insurance system, an IBM mainframe and the I90 Insurance package. Drop the elements on the Scratchpad. A blue Application Component and name it Avion, A green Node element to represent the mainframe and a green System Software element for the I90 package (figure 3).
The statement also contains a number of relationships. Use the appropriate connectors (arrows) to establish the relationships. Verbs often denote or imply relationships. The phrases "the Avion Insurance system is hosted" and "using the I90 insurance package" describe relationships.

The Avion application is "realized", or made possible, by the I90 Package which is hosted on the Mainframe. Where the Association Relationship is used, ALWAYS add an explanatory label like "Hosts" (figure 4).



However, let's say you can't verify the last two elements from a primary source. On the balance of probability you're probably correct, but you can't prove it. So you MUST attach a Note element. If this ambiguity is a RISK to the solution then set the element's color to red.

The model's Note elements provide a solid foundation for well-formed questions to the Subject Matter Experts (SME). Be sure to make the Note as comprehensive as possible.

13 Create the Business Views

The Business Context View is the first "real" view, meaning one that will be shared with the team. Its purpose is to identify business components and set the context for the solution.

13.1 Method

1. Open Views - Business Layer - Business Context View.
2. The view will be blank
3. Set the Viewpoint to Business Process Cooperation
4. In the Models pane on the left expand the Business folder
5. Below the Examples folder are all the Business elements you added to the Scratchpad
6. Select these elements and drop them on the view

METHOD NOTE: If you have too many elements then create an overview. For example, the Business Context Overview may simply contain the organization's locations. Then create Detailed Business Context Views for each location and put drill downs to them in the overview (see Example B).

METHOD NOTE: Detail view elements may benefit from an identifying prefix. For example a Firewall in Brisbane woold be Brisbane-Firewall.

7. This process will reveal unresolved relationships (elements with no connectors)
1. Resolve these using primary sources
2. Where primary sources cannot resolve the relationships, Note the element
8. Scan the Functional Requirements (FR) prepared by the Business Analysts
1. Test every occurrence of an Actor or Role (active entities) in the FR against the Business Context View
2. Add any new elements discovered
3. Analyze each new element adding related elements like, Locations, Products or Processes, and their relationships
9. Scan the Functional Requirements (FR) AGAIN
1. Test every occurrence of a Business element
2. Add any new elements discovered
3. Analyze each new element adding related elements and relationships
10. Examine the view and Note ALL unverified elements and unresolved relationships
11. Take the view to the appropriate SMEs for verification

The PraXtice model is the best version of the truth we have. It MUST ALWAYS be up to date and well-formed.

13.2 Validation

A Business Context View is well-formed when:

• All Business components documented in primary sources appear in the view either as discrete elements or as a Set member
• The view contains all inferred elements
• The view has been verified by SMEs
• The view has been validated by another Architect familiar with the Architecture Vision
• The view can be used to explain the current business context

13.3 Architect's Notes

All Business elements have now been identified. The subsequent discovery of a new Business element is a discontinuity and must be RED Noted as a RISK.

14 Create the Application Views

The System Context View is the second view created in FreePraXtice. It shows the relationship between the "existent" and "proposed" components. As such it is a bridge between the current and target states.

The System Context View is a more sophisticated view in that it is a "boundary spanning" artefact that connects the Business and Application layers.

14.1 Method

1. Open Views - Application Layer - System Context - System Context View
2. Set the Viewpoint to Application Usage

METHOD NOTE: This will grey out some elements and limit the palette

3. In the Models pane expand the Business folder
4. Select the Actor, Role, Process and Event Business elements and drop them on the view
5. In the Models pane expand the Other folder
6. Select the Location elements and drop them on the view
7. In the Models pane expand the Application folder
8. Select the Application elements and drop them on the view

METHOD NOTE: There will be elements that you do not need; this is simply a fast way of composing the view

9. Infer components and relationships
10. This process will reveal unresolved relationships
1. Resolve these using primary sources
2. Where primary sources cannot resolve a relationship, Note the element
3. Test every element
11. Examine the view and Note ALL unverified elements and unresolved relationships
12. Take the view to the appropriate SMEs for verification

METHOD NOTE: At this point the System Context View should contain all the applications and Actors related to the solution

METHOD NOTE: The subsequent discovery of a new system is a discontinuity and must be RED Noted as a RISK

13. In accordance with the Architectural Principles for this segment, add to the view the minimum number of Application elements that can represent the solution. Typically this will be a small number and may even be one
14. Add the relationships

METHOD NOTE: There is no correct number of elements used to record a new solution. The guiding principle is the purpose of the view. The purpose of the System Context View is to set the solution in context for the following solution design tasks.

15. All systems related to the solution have now been identified

The PraXtice model is the best version of the truth we have. It MUST ALWAYS be up to date and well-formed.

14.2 Validation

A System Context View is well-formed when:

• All components documented in primary sources appear either as discrete elements or as a Set member
• All components documented in Functional Requirements appear either as discrete elements or as a Set member
• The view contains all inferred elements
• The view has been verified by SMEs
• The view has been validated by another Architect familiar with the model
• The view is accepted by the Development team

14.3 Architect's Notes

The System Context View ties Actors to Applications. See the example System Context View (See PraXtice model).

All System elements have now been identified. The subsequent discovery of a new Application element is a discontinuity and must be RED Noted as a RISK.

15 Create the Solution Design

A FreePraXtice Solution Design consists of a minimum of two views the Application Structure and Application Behaviour. It also establishes an Architecture Decisions Artefact.

15.1 Method

Solution design is a heuristic process that varies considerably between Architects. However, research suggests some pointers that have been encapsulated in PraXtice.

1. Open Views - Application Layer - Solution Design - Application Structure View

METHOD NOTE: This view is the "point of origin" for the Solution Design

2. Group the Functional Requirements provided by the Business Analysts into groups of related concerns. Each group represents a potential component
3. Examine the Systems Context view it will often identify, directly or by inference, existing components that are candidates for reuse. Create a representative element for each candidate component
4. Compare the capabilities of each candidate component with each group of related concerns. Where it's appropriate select the component for reuse and add its element to the Application Structure view
5. The remaining groups of related concerns will require new components. Create representative elements and add these to the view
6. Record ALL these "design decisions" in an Architecture Decisions Artefact (example in ProPraXtice) as you proceed. Use a simple text document if your organization does not have one.

PraXtip - Record your reasoning



7. Arrange and connect the elements to reflect the components' organizational relationships (aggregation, composition etc)

METHOD NOTE: In figure 7, the iToll application consists of a Main control component, Messenger and Calculator components plus some interfaces. So, iToll can be considered a single or multiple components. It depends on your perspective

8. In the Model pane under Views - Application Layer - Solution Design select the Application Structure View and duplicate it

   PraXtip - Beware copying creates new elements

9. Rename the Application Structure View (copy) to Application Behaviour
10. Change focus to the Application Behaviour View
11. Delete from the view ONLY, ALL the relationships (connectors)
12. Reconnect the Application elements using the behaviour relationships (connectors) only; Trigger, Data Flow, Serve and Access

METHOD NOTE: You may add external systems from the System Context View where these help to explain the Behaviour. (See figure 8)



13. You now have a basic macro level Application Component Model

METHOD NOTE: High level components may require their own detailed views. The shortcut Icon on the Rules Engine Service (figure 8) connects the Detail Rules Engine Application Structure View (figure 9)



14. Now complete the Micro design for each subcomponent in a form that satisfies the Development team. This can take any agreed form. It could be design notes, pseudo code, structured English, UML diagrams, flowcharts or even actual code

The PraXtice model is the best version of the truth we have. It MUST ALWAYS be up to date and well-formed.

15.2 Validation

A Solution Design is well-formed when:

• BOTH the Application Structure and the Application Behaviour Views are complete
• The Application Structure and Behavior views have been traced back to the System Context View and all relationships resolved
• Both views have been verified by SMEs
• Both views have been validated by another Architect familiar with the model
• The individual Application component micro designs have been validated by another Architect familiar with the model
• The individual Application component micro designs have been accepted by the Development team

15.3 Architect's Notes

The line between architecture and design is often blurred. PraXtice considers architecture to be concerned with the properties of the components that constitute the solution. Component design (micro design) is the implementation details of those properties. Architects need to work closely with Development teams on micro design. ProPraXtice covers this topic in detail.

16 Create the Technology Views

FreePraXtice has two Technology Views. The Technology View, a logical description of the infrastructure and the Technology Usage View, which is a solution deployment view.

16.1 Method

1. Open Views - Technology Layer - Technology Usage View
2. Set the Viewpoint to Technology Usage
3. In the Models pane expand the Technology & Physical folder
4. Select all the Technology elements (green) and drop them at the bottom of the view

   PraXtip - Makes the next task easier

METHOD NOTE: You are mostly interested in Nodes and Networks. There will be elements that you do not need Artifacts for example

5. Infer components and relationships
1. This process will identify new components and relationships
2. Test every element
3. Resolve details using primary sources
4. Where primary sources cannot resolve a detail Note the element
6. Examine the view and Note ALL unverified elements and unresolved relationships
7. Take the view to the appropriate SMEs for verification

METHOD NOTE: At this point the Technology Usage View should contain all instances of technology components that support the solution

8. In the Models pane expand the Applications folder
9. Select the Application elements (blue) and drop them at the top of the Technology Usage View
10. Delete from the view ONLY, all greyed out blue elements with the exception of Data Objects

    PraXtip - Usually a good idea, but not always

11. Infer components and relationships
1. This process may identify new components and relationships
2. Test any new elements
3. Resolve details using primary sources
4. Where primary sources cannot resolve a detail Note the element

METHOD NOTE: The Technology Usage View is now complete

12. Duplicate the Technology Usage View as the Technology View
13. Change focus to the Technology View
14. Set the Viewpoint to Technology
15. Delete from the view ONLY, ALL Application elements
16. Delete duplicated element types

    PraXtip - Single element for each type?

METHOD NOTE: Where there are multiple instances consider creating Set Elements and Pattern Views. For example, John, Paul and Ringo are all Standard App Servers (see PraXtice model)

17. Delete other element types until the view is fit for purpose
18. Take the view to the appropriate SMEs for verification

METHOD NOTE: At this point the Technology View should contain all the technology components types that support the solution (See PraXtice model examples)

The PraXtice model is the best version of the truth we have. It MUST ALWAYS be up to date and well-formed.

16.2 Validation

The Technology Views are well-formed when:

• All components documented in primary sources appear in the views either as discrete elements or as a Set member
• The views contain all the Technology elements that can be inferred
• The views has been verified by SMEs
• The views has been validated by another Architect familiar with the model
• The views are accepted by the Infrastructure and Development teams

16.3 Architect's Notes

All Technology elements have now been identified and Application elements have been assigned to their hosting technology nodes. The subsequent discovery of any new element is a discontinuity and must be RED Noted as a RISK.

17 Wrapping it up

By this point you should have a very practical basic architectural model. This will improve the quality of your architecture and allow you to actually do architecture rather than wasting your time compiling inaccurate documentation that nobody uses.

If you find FreePraXtice useful we urge you share it with your friends and colleagues? When you find FreePraXtice is actually paying back the time you invested in it we suggest you purchase ProPraXtice. If you think FreePraXtice has improved your life; you ain't seen nothin' yet!

ERRORS AND OMISSIONS

As Architects we understand that despite our best efforts errors will be made and omissions will occur. PraXtice has a simple philosophy for handling this. It is that we don't mind being proved wrong, but we do mind being wrong. So, if you find something that's wrong we'd be appreciative if you would take the time to send an email to info@praxtice.com.au

About the Author

Dr. Thomas Hope has more than thirty years industry experience including thirteen with IBM. He is a member of IASA, the Guild of Business Architects and the Association of Enterprise Architects. He holds a Master's degree in Business IT Management and a PhD from the University of Technology, Sydney where he continues to be involved in architecture and professional practice research.


PraXtice Every Day!