Changing Platforms...

Gentle Reader,

Lately, I have become underwhelmed with the exposure I have gotten using the Blogger platform. I originally selected Blogger, due to its ownership by Google. I assumed that I would automatically get better Search Engine Optimization (SEO), but I was mistaken.

So I have spent the last couple of days migrating the Enterprise Architecture portion of the BLOG to Wordpress. you can find it here: https://enterprisearchitect.wordpress.com 

Soon, I will also migrate the Photography section to a new BLOG, and I will update this post to reflect that. So come on over to Wordpress & take a look around. That's where you will find all new entries.

Thanks for joining me on this ride....

Mark Spencer

The Architectural Canvas

Gartner has created an excellent view of Enterprise Architecture. This view (shown above) describes how the Architecture can fall into four main quadrants (Gartner is famous for its “Magic Quadrants” !). These quadrants are described by their relationship to being Tactical vs Strategic, and Local vs Enterprise., which are represented along the X and Y axes:

• Enterprise - this is an architecture that spans the entire organization, regardless of department. It should envelop the Strategies and Capabilities that the Enterprise wishes to achieve. 
• Local - describes an architecture that is more subjective, perhaps being an architecture for defining the individual systems that the IT Department uses.
• Strategic - these architectures are designed to line up with the Enterprise’s Strategies and Capabilities.
• Tactical - these are architectures which align to objectives.

The Navigate method of applying the TOGAF architectural framework follows this model fairly well. And one of its principles is to understand who the members of the Enterprise Architecture team are, and how they participate. This should include stakeholders from the Enterprise, as they typically provide the Strategies which Enterprise Architecture should be delivering upon. In the Navigate method, there is an exercise which helps understand where on this canvas the individual members lie - which helps understand their role and what they deliver.

Of course, everybody wants to be the Enterprise Architect. But if we examine what the members do, we can derive how they fit. In terms of the Canvas, the four quadrants are first bisected by a line which defines Vanguard Architecture vs Foundational Architecture.

• Vanguard Architecture - this is the innovative, forward-looking architecture. It commonly looks for new ways to achieve the Strategy of the Enterprise. It will examine new technologies and methodologies. In Gartner’s view, this is the Architecture that considers the Capabilities of not only the Enterprise, but those of its Customers, Suppliers and Competitors. This is referred to as “Outside-In Architecture”.
• Foundational Architecture - this tends to be thought of as more of a Traditional way of looking at ONLY the Enterprise and its capabilities, often re-defining Services to be more efficient. This is referred to as “Inside-Out Architecture”.

The two dashed red lines describe the traditional Roles within the Architecture realm. Many Enterprises are moving away from a model where there is a discrete group of Architects that participate in the Architecture field, and move towards a more Federated or Social model. This implies that the Architecture group is such more broadly defined, just as their roles need to be.

• Enterprise Architects - look at the Enterprise holistically, helping the Enterprise understand how to change to suit an ever-changing landscape. They build out the Conceptual Architecture required for transformative change.
• Principal Architects - typically are Solution Architects, but tend to look less at the entire Enterprise, and more at individual Lines of Business. They look after an individual set of Capabilities. 
• Solution Architects - tend to be Project-focused, with a solid understanding of the systems which provide the Services of the Enterprise. They build out the Logical Architecture, defining how systems will deliver the Services, and their requisite Functional Requirements.
• Technical Architects - also Project-focused, they develop the Physical Architecture by interpreting the Logical Architecture and applying the Non-Functional Requirements required to satisfy the Solution.

A solid Federated Architecture will have members that fall across all of the quadrants, delivering highly valuable architecture that delivers the Business Outcomes that are defined in the Strategies. This will in turn provide a high degree of traceability from the Stories and Activities defined in the CLIP Framework all the way back to the Business Outcomes.

CLIP Mapping

In this blog entry, we will try to get a better handle on some of the relationships the CLIP Framework has to the actual business itself. Without having tangible Business Outcomes, the framework has no value to the business.

C is Conceptual

Down the middle of the diagram, we see the hierarchy of the framework. As we have seen in previous entries, the top of the hierarchy is the Strategy. The term strategy is defined as a plan of action or policy to achieve one or more goals under conditions of uncertainty. These are the Outcomes the framework seeks to achieve. The next line is the Capability, which for our purposes is synonymous to the Objective - note that there could be multiple Objectives ! In business terms, the Capability aligns to the things the business does to offer its products or services. The Strategy & Capabilities are the foundation of the Conceptual Architecture. If the Strategy is to provide an Omni-Channel means of selling to customers, the Capabilities are to deliver the shopping experience in multiple ways - through both store-front operations and through an eCommerce web-site. The Conceptual architecture provides a means of delivering those Capabilities to meet the overall Strategy.

L I for Logical and Informational

The business will develop Processes for repeatability. Multiple Processes bundled together become the Capability. For example, an eCommerce web-site is a Capability - it is a means of selling products or services to a customer. There might be more than one Capability, such as brick and mortar stores as well as the eCommerce web-site. But the Capability must encompass a number of Processes, like being able to browse the selection, add them to a virtual shopping cart, calculate the price, taxes and a running total. All of these Processes sum up to a Capability. And, just as every process sums up to a capability, a number of Services sum up to a process. Discrete services are often reusable. The process of building a virtual shopping cart in an eCommerce web-site is exactly the same as checking out a client at a cash register in a store. Informational Architecture is about transformation. A number of services need to work together to form a process. Those services are all dependent on information (raw data which has been processed into a usable format) which may come from disparate sources. And each of these sources will have their own way of storing, manipulating and serving that information, so often there is some form of translation (transformative process) which makes the information usable to the services. When building out the systems to support the Capabilities, the Processes & Services provide the Functional Requirements. These describe how the system and the associate interact to perform the Processes.

P for Physical

The Activities and Stories are important to the Framework, as they describe the manual steps required to perform a set of tasks. For example, a store associate might receive an item from a client. They find and scan the barcode on the label, check that the description matches the garment, the system adds the garment to a virtual shopping cart and calculates price, discount and taxes, which are displayed on the screen for the customer and the associate to see. They then make decisions about which activity is next, depending on the form of payment a client wishes to use. So the Stories describe how the associate interacts with both the client and the system to perform all of the activities. The Activities drive out the Non-Functional Requirements. These are usually about the time it takes to perform a transaction, or how many transactions a system can handle in a given time-period.

Changing Things Up…

So I have decided to take my writing more seriously, including being more diligent about my blogging, as well as possibly developing some ideas I have had about drafting a book related to my profession. My father - who was an academic all his life - once told me “You’re not really a professional at ANYTHING until you have been published !”

The POWER Method

In a previous blog entry, I discussed the POWER methodology for writing:
* Plan
* Outline
* Write
* Edit
* Release
This is a powerful (see what I did there ?) method that I like a lot. But I needed to create a workflow that matched this methodology. And frankly, editing my blog entries in BLOGSY (an iPad application) is cumbersome. Worse, the native WYSIWYG editor Blogger publishes online is fraught with various peril. For whatever reason, I cannot make the final copy look like the editor copy, which is VERY frustrating !

A New Tool

I have coughed up $24 USD & purchased a copy of Scrivener 2. It is the “Writers Choice” according to many of the online reviews. Some of the features I really like are:
1. A binder/page concept similar to Microsoft OneNote
2. The cork board allows me to write synopses of the sections or pages of write
ng, allowing me to write the ideas down & play with the organization later
3. The ability to publish HTML Markup - to post directly into Blogger
4. The ability to publish in ePub format for the next Great Canadian Novel (no, not really)
5. The ability to publish in Kindle format - why limit my market ?

Please bear with me as I learn the nuances of this tool and the power it gives me to just write.

Framework Flexibility - From CLAP to CLIP

As many readers may have noticed, there are some fairly significant gaps in the CLAP Framework. In the perfect world, it is really intended as a guide for how to execute Business Goals into practical IT Projects. But there  may be some flexibility in the simplicity of that framework.

A colleague pointed out that maybe the missing component wasn't necessarily the Application, as those needs are covered off in the Functional Requirements. He suggested that instead the framework should consider the Information Architecture itself.

For the purposes of this framework, lets consider that data is the raw input of a process, and information is the output. Information needs to have a defined structure and each element has a distinct meaning. Consider the difference between distance an speed. Distance is a unit of measure, denoting how far something is. Speed is the distance divided by the time taken to travel the distance. Speed is the result of a process. applied to the data.

In the CLIP Framework, the notion of Information Architecture is added. It describes the processed data, its flow from system to system, and its attributes. For example, is information synchronous (live from a source) or asynchronous (delivered by a different process). Further, we see where the Requirements and Standards get applied, and how Security Requirements need to be considered through every step of the process.

Finally, we see the Validation step happens just before the solution is transitioned to Operations. It asks the question "Did the final physical solution deliver what was designed ?". Arguably, there is another validation step, which asks the question "Does the Solution Architecture satisfy all of the requirements ?".

The validation is key, as this largely waterfall process needs to map the entire solution all the way back to the original Business Activities, described in the functional & non-functional requirements. As you can see, the framework is flexible enough to be applied to many IT Goals, and not so rigid as to be unmanageable.

Failure Mode and Effects Analysis

It is said that a chain is only as strong as its weakest link. In IT terms, we refer to a Single Point of Failure (SPOF) as being one of a systems weaknesses. Technology Architects spend a significant amount of time attempting to identify and mitigate these SPOFs. But what if there is a large number of points of failure ? How does an Enterprise IT organization prioritize which SPOFs to mitigate first ?

Enter Failure Mode and Effects Analysis. The idea is to first identify the Points of Failure, then identify:

• Severity of the Failure - How would the failure effect the business of the Enterprise ?
• a higher number here reflects greater risk should a failure occur
• Occurrence of the Failure - how often could the failure happen ?
• a high number here represents greater likelihood of the failure occuring 
• Detection of the Failure - how would we know if the failure occurred ?
• a high number here represents a less-detectable failure, and therefor a greater risk

These three items are evaluated on a scale of one to ten, with ten being the highest. When multiplied together, these three factors comprise a Risk Priority Number (RPN). If effect, the higher the RPN, higher the risk of Failure. From there, we can create a prioritized list of tasks which will mitigate the known risks of a system.

Illustration of an FMEA Example

Generally speaking, as the IT organizations works through the top few items on the list (from higher priority to lower), the overall risk to the system decreases dramatically, along the lines of the 80/20 rule. FMEA is normally applied to manufacturing or development processes, but can easily be adapted to suit IT systems as well.

RASCI for Project Decisions

When Enterprises embark on large projects, they build out a Project Team. This team consists of Stakeholders, Project Manager(s), EA, TA, SA, Implementation resources and Operations. The challenge happens when Project Decisions need to be made - who makes the call ?

Enter the RASCI. It is a matrix of the key roles, and who should be:

• Responsible
• Accountable
• Supportive
• Consulted
• Informed

Assuming we use the RASCI members as defined in the PMLC, we would end up with a table like this:

	Stakeholders	Project Manager	Business Analyst	Enterprise Architect	Solutions Architect	Technical Architect	CoE	Operations
Budget	R	A	S	C	I
Timeline	R	A	S	S	S	I
RACI	I	R	I	I	I	I	I
Project Charter	A	R	S	S	C	I	I	I
Project Plan	A	R	S	S	S	S	C	I
Functional Requirements	I	I	R	A	A	A	C	I
Non-Fuctional Requirements	I	I	R	A	A	A	C	I
Conceptual Acrhitecture		I	S	R	A	A	C	I
Logical Architecture			I	S	R	A	C	I
Physical Architecture				I	S	R	A	I
Detailed Build Plans					I	S	R	A
Runbooks & SOP						I	A	R

Now that the "theory" is out of the way, let's take a look at a practical example:

The project is building out network infrastructure to support a new group being added to the Enterprise. So possible questions which might arise are:

1. A Stakeholder doesn't want to change the Firewall Rules. Who is authoritative ?
• The Technical Architect "owns" the Physical Architecture, including decisions about their use & configuration
2. Who should be informed of a change in Project Scope ?
• Since the Scope is part of the Project Charter, the Project Manager is responsible to inform every role on the RASCI with a corresponding letter in the matrix. So everybody.
3. What is the role of the BA in the Detailed Build Plans ?
• None - there is no corresponding letter in the matrix

As you can see, the roles & responsibilities are clearly defined, so that everybody on the project can determine who "owns" the decision. That's not to say that the project Stakeholders won't over-rule some decisions, but in general they don't.

Pulling It All Together - CLAP + PMLC

In a series of previous posts, we took a look at various frameworks for bringing valuable IT Services to an Enterprise. Starting with the CLAP Framework, we saw took a look at a basic way of starting with Business Activities and building the necessary Conceptual, Logical & Physical Infrastructures to deliver valuable IT Services.

Next, we saw how to use a tool like the ERRC Canvas to achieve the Enterprise Strategy, by mapping the strategy to goals & objectives. The key function of the canvas is to separate the objectives into four areas: Eliminate, Reduce, Raise & Create. 

Once divided, metric for success are applied, and plans can be created. These plans can be prioritized and dependencies mapped. Getting from Business Strategy to IT Execution is no easy feat - so this post describes a method of execution.

Of course, understanding goals as they relate to Strategy is also very important. We took a look at how to create SMART Goals.

Illustration: CLAP and PMLC Together on One Page

We are now in a position to pull all of those concepts into one diagram, shown above. I have attempted to layer the various concepts together, and embellished them with some extra information, such as when a project can expect to need to engage various roles within the RACI.

Finally, we see three vertical lines which describe a form of IT Governance. In a future post, I will describe the make-up of the ARB/TRB and explain the importance of the Architectural Validation Plan.

Business Service Model for IT

IT exists for one purpose: to provide the tools necessary to enable Business Activities. Like we saw in the CLAP Framework, Business Capabilities are made up of a number of discrete Business Activities. But it is in the delivery of the Business Capabilties as a Service that IT provides value to the Enterprise.

The model for a Business Service is clearly defined by the ITIL framework. In short, it is composed of People, Process and Technology. Certainly, the framework also describes the meta-data, which includes the Service Owner, the Service Consumer and the Service Provider.

Once the functional and non-functional requirements of the Business Capabilities are mapped out, the application and its underlying infrastructure become straightforward to build out. As I have posted about previously, the Project Management Life Cycle can be easily applied to deliver these capabilities to the Enterprise. Of course, more than one capability can be provided by a single service. Often many services get grouped together to form a broader service.

There is also another relationship hidden in a simple model like this one. The degree to which a process is repeatable (and can therefore be automated) has implications to the People part of the equation. The more highly repeatable and automated a process is, the lower the required skill-set for the labour, which should in turn lower the cost of the Service to the Enterprise.

Posted with Blogsy

Mapping Projects Back to Strategies

In order to be successful, IT needs to closely align its services to the Business's Strategy. This requires that the Enterprise Architecture group have a clear idea what the business strategies are! While I am actively studying the TOGAF architectural framework, I recognize that many Enterprise customers are unwilling to completely "buy in" to a specific framework. So this series of BLOG entries look to fill the void.

Illustration: Mind Map of Strategy to Goals to Projects

In a previous post, we described how the ERRC Canvas can help support the Strategy, by helping achieve the Goals. As we move from left to right through the above illustration, multiple Goals might be required to realize a Strategy. The ERRC canvas is a great tool for identifying activities, which broadly fall into the categories of Eliminate, Reduce, Raise and Create.

Building on that theme, and assuming we want SMART Goals (Specific, Measurable, Attainable, Relevant, and Time-based), we can identify the Metrics, which are the measurements of success. Assuming we can cleanly map between the ERRC Canvas (representing the Goals) and the SMART Metrics for those avtivities, we can derive a Plan or Project to implement those Goals.

On the far right, we see the conventional wisdom that Project Plans contain elements of Budget, Timeline & Resources. The Project Plan is a culmination of the Strategy (Why), the Goals (What), the Metrics (How Much) and the Plan (Who). The Project Charter can define the When, as well as any required sequencing.

If you're curious about how projects evolve from a Project Charter through to successful delivery of the objectives & goals, take a look at my previous entry, entitled Project Management Life Cycle. I cannot stress enough the importance of proper planning ! When in doubt, think of the axiom "measure twice, cut once".

Posted with Blogsy

Project Management Life Cycle

Illustration: Project Management Life Cycle

We all know that IT projects don't just happen. They usually start with an idea that gets socialized internally, until somebody decides it is interesting enough to write a business case, justifying why the idea might be good for the Enterprise. The Project Management Life Cycle (PMLC) walks the reader, from left to right, through all the components of a project. It assumes the project has been instantiated and has executive sponsorship. Other activities prior to the project itself include the Opportunity Assessment, a Cost/Benefit Analysis, and likely ROI and TCO studies.

The PMLC illustration above is designed to show three things at each stage: the roles that contribute to the project, their responsibility and their deliverable. Starting on the left, the Stakeholders typically sit on a Steering committee, and provide budgetary approvals for the project.

The project is run by the Project Manager, who is responsible for budget, timeline & resources. They usually draft the Project Charter, which defines the objectives and scope of the project. They are responsible for reporting back to, and taking direction from the steering committee. It is their responsibility to deliver the project to successful completion.

The Business Analyst does a lot of leg-work, dealing with the stakeholders to understand requirements, both functional and non-functional. They will take raw data they have collected, and produce information which is valuable to the project, and consumable by all members of the project team.

Now that you have a general idea of the flow, you can interpret the rest of the illustration for yourself. Other information that will later become key is called the RACI. It is an artifact that names all of the roles (as seen in the illustration), and determines who is Responsible, who is Accountable, who is Consulted and who is Informed when a project decision has to be made.

This is a general look at how IT projects move through their life cycle. In a future post, I'll overlay the CLAP Framework, to pull together all of the concepts into a single view.

Posted with Blogsy

From Business Strategy to IT Execution

Illustration - Strategy to Execution

As we have seen in my previous posts, I am always keen to tie IT Activities to Business Strategy. Whether it is in utilizing the CLAP Framework to map Business Activities to physical IT infrastructure, or in achieving your goals using the ERRC Canvas, the end-goal is always to drive Business Value.

In this basic diagram, the basic questions of Who, What, Why and How are directly addressed, leaving the When up to the Executive sponsors to decide in the Project Charter. The centrepiece is the ERRC Canvas, which helps define the Objectives (the What) & IT Activities that would meet the Goal. As with all SMART Goals, the element of Metrics help define the How.

Finally, the Plan is actually the domain of the Project Management Office. It would include the Project Charter and supporting artifacts, including dependency maps and budget estimates. Conventional Wisdom is that the Project Manager is responsible for Time, Resources and Budget.

Posted with Blogsy

SMART Goals

When setting Goals, there is a great model to follow that will help in achieving them !

 

 

S - needs to have enough detail.

M - needs to have actual metrics by which to measure success

A - needs to be something that is possible to achieve

R - if the goal doesn't have any purpose, what's the point ?

T - needs to have a due-date to work towards

 

 

A good example of a SMART Goal would be: "I am 240 lbs today. I want to get my weight under 200 lbs by Christmas."

 

 

Posted with Blogsy

How to Achieve Your Goals - the ERRC Canvas

Illustration - the ERRC Canvas

 

As you might already know, I love canvases. They provide a simple means of communicating ideas. The image at left describes a very basic canvas to convey a very powerful idea: What do I have to do to achieve a Goal ?

In another BLOG entry, I will discuss Goals - specifically what makes good goals vs what makes difficult goals. If you want to do some homework, in a future BLOG I will discuss SMART Goals and why they are effective.

In general, and especially true in Business and IT, Goals can be achieved by placing tasks into one of four broad categories - Eliminate, Reduce, Raise, Create. Let's take a closer look at these simple yet powerful concepts. But remember, Goals are only important as a means of realizing a Strategy. Often, strategies are realized through the successful completion of a number of goals. Equally, there may be more than one Strategy being realized !

Eliminate - this is a pretty straightforward concept. Ask yourself the question "What do I need to remove from the environment to achieve the Goal ?". It could be simple, like lets eliminate duplicate services. If two systems can service the same Business Activity, then one of them is redundant. Ergo, one of them could be eliminated & help achieve the Goal.

Reduce - this is also a simple concept. If the Goal is to "decrease server sprawl", then the use of a consolidation solution (think of server virtualization) would reduce the number of physical compute hosts required to service the the Business Activities. Implementing server virtualization reduces the number of server's required to host the workloads, realizing the Goal.

Raise - this often goes hand-in-hand with Reduce in that often reducing one element will raise another. In the above example, we looked at implementing server-virtualization as a means of reducing server sprawl. It also has the opposite effect of raising the rate of physical server utilization !

Create - This is the tricky one. What do I have to ADD to the environment to achieve the goal ? Fortunately, the context of these canvases is around achieving IT Goals, in alignment with Business Strategy. So you might create a new process for deploying the virtualized servers into the compute environment, perhaps to enable a new Business Activity.

Now, each one of these sections of the canvas can contribute to the overall goal, meaning you might have many entries in each quadrant, all in alignment to the goal. This helps develop a list of activities which might need prioritization & dependency-mapping in order to complete. But at least now you have a defined method of achieving the established goal !

 

Posted with Blogsy

CLAP Framework for IT

Many Enterprises struggle with IT frameworks. These frameworks are meant to help turn Business strategy into executable plans. Some frameworks, such as TOGAF or Zachmann will help an Enterprise IT group understand WHAT it needs to do to achieve its goals. Other frameworks, like COBIT or ITIL will further explain HOW to achieve those goals. When an Enterprise does not follow any of the established frameworks, they will often try to devise their own. The diagram above illustrates one such framework - the "CLP" framework (the "A" was added later, after missing information was identified).

Conceptual - this stage of the framework takes the Business Activities into account. Each discrete activity can be mapped out as a few elements in a process, describing a single activity. An example might be "calculate price".

Logical - this stage maps the discrete activities required. To calculate price, we need some information from a number of sources, such as the gross price, a taxation rate, a discount and a profit margin. Further, architectural governance (standards) are applied, such as use of a Linux operating system, or mandating a particular security framework. Finally, Non-Functional Requirements (NFRs) are described, such as how quickly a system must respond or how many transactions per minute the system must satisfy.

Application - this stage is where we begin to apply some business logic about what to do with the information. It maps out what the information should be expected to look like, such as expressing numbers in Currency notation, with two decimal points of precision. It will also describe any user interfaces and other means of accessing information. It specifically maps business activities to Functional Requirements.

Physical - this final stage helps identify all of systems that are required. Items such as CPU utilization and storage requirements are calculated to determine how best to implement the system into a computing environment. It describes systems interactions in terms of protocols and transports.

This is not an exhaustive look at frameworks, and many Enterprise Architects will keenly assess missing elements from this simplistic framework. But, executed properly, a framework such as this one could be sufficient for an Enterprise to begin taking advantage of IT to realize their business strategy.

Posted with Blogsy

Bracketing Those Shots

Round Bales in the Field

Lately, I have changed my photography process. It started when I discovered that Magic Lantern was available for my Canon 60D. For those wondering what that is, think of a firmware add-on which extends the capabilities of your camera. Near and dear to my heart, it is open source software that the camera reads from the memory card as it starts up, so no concerns about "bricking" my camera ! More importantly, it has added a host of options that I am really starting to enjoy using.

The default Canon firmware has a setting called "Auto Bracket", which allows the photographer to set up a three-shot bracket around the optimal exposure, and the photographer then sets the number of EV (in 1/3 stop increments) between captures. With Magic Lantern, the photographer has a lot more control - either choosing how many shots in the bracket manually, or letting the software determine what it needs in-camera.

On the back end, Lightroom CC has the ability to take the bracketed shots and merge them into one, creating an HDR-style photograph without all of the weird side-effects. There is also a nifty function called "anti-ghosting" which will attempt to eliminate any elements that occur in one of the frames but not all of them - like a truck or bird passing through the frame !

So all the way through, my choices have encouraged me to create bracketed photos, which bring out an added feeling of depth and warmth. These various functions, when properly mixed, have made complex techniques very straight-forward, allowing me to concentrate on the composition more. And that I where I know I need to focus more of my attention !

Posted with Blogsy

Staying Alert When Shooting

I went out on a shoot last night. There were a number of shots I have been meaning to take, but the conditions haven't bee favourable. This first one I have been I visioning for months. There's an on-ramp into Stoney Trail (Calgary's ring road) which has runoff basins on either side. They fill with the runoff from the highway, and the rainwater is meant to evaporate, but never seems to.

I like to shoot frames in triplets for HDR purposes. It actually achieves two purposes. The first frame is perfectly exposed. The second is 2/3 of a stop over, and the third is 4/3 of a stop over. This gives me the ability to bring up the dark & shadowy spots. Then after I apply the HDR process, I can always play with the exposure rate to get the mood I am looking for, without losing the details.

The challenge To shooting triplets at night is that you have to remember to be situationally-aware ! I was so concerned with getting the exposure correct, I failed to notice the traffic. The first exposure was about 4 seconds, the second about 6, and during the final 9 second exposure a pickup truck came racing through my shot !

Posted with Blogsy