I recently saw an email from someone at small-ish bank. Saying our BPA project has gone significantly over budget. So now isn't a good time to ask the business for money to get an SITP planning solution.
The logic of not allocating funds to Strategic IT Planning - i.e. solutions that specifically focuses on ensuring IT costs are reduced, and the scope and cost of initiatives are well understood before work undertaken, and understanding the impact of changes as they occur - when someone has just had experienced a project that has demonstrated the need for SITP systems doesn't make a great deal of sense to me.
I also frequently encounter comments to the effect that the way our strategy & architecture function works (usually as internally oriented function producting documents for their own gratification) isn't really that effective. So we are not going to explore an SITP solution that would enable this function to operate effectively? Rather we are going disband the unit and distribute the function into business units (that operate on tactical and point solutions). So we know we need to think strategically - but at present we can't do it - so for a year to two we will pretend it isn't necessary.
I see this kind of anti-logic all the time. In many aspects of life.
I am reminded of the people to whom I recommend yoga. But I am told told "I am too stiff and stressed" to do yoga, presumably they are also too fat to diet, too unfit to exercise, too uninformed to educate themselves.
If they said we like wasting money, we get off on it, it means we can buy lots of cool technologies to play with. At least one could have respect for them at one level (honesty). Or if they said we really don't understand what strategy & architecture is about or how to get value from it we are really over grown SW developers or systems engineers and our heart is in coding and playing with operating systems. One could have respect for them. Or if they said - I am looking forward to a future or obesity induced health problems, stiffness and stress related disorders - this is a just penance for past behaviour. You could see at least that they are considering the impact of their unwillingness to change their habits. It seems to me that that these people don't even seem self aware enough to do this?
I am tempted to conclude that one thing all these people have in common is that they don't have the energy, will or initiative to change. But unfortunately some of them are among closest friends - so I really don't know what to make of it.
Friday, March 6, 2009
Monday, March 2, 2009
Business analysis and visioning
I believe a simple structured way to analysis is required. I think most analysis can be organised around simple set of canonical model (Goals, Facts, Beliefs, Recommendations).
To be useful the relationships between concepts need to be weighted. But the 1st step is to understand the relationships between Goals and Recommendations (via Facts and Beliefs).
When one reads most analysis documents and tries to assemble a model like this - but usually finds large gaps and inconsistencies (which is really just feeble) e.g. the recommendations can be substainiated or the basis of them is not explicit.
This analysis may strategic or tactical, focus on a current problem or future state (visioning), it may be technical or non-technical.
Forcing the thinking into this simple model helps people understand the basis of beliefs and recommendations.
Goals: are things you are trying to achieve. Sometimes technical people also refer to these as principles e.g. non-functional requirements e.g. reliable - but in fact they are goals.
Issues: are problems you are trying to address (they are actually goals stated in a different way)
Facts: are facts i.e. they are not disputable.
Beliefs: should be based on Facts and relate to Goals/Issues (if they don't relate to Goals/Issues they are not that useful)
Recommendations: are actions based on Beliefs to achieve Goals/address Issues.
Concepts: are a grouper for things terms, patterns, principles, ideas we may refer to when we discuss Goals, Facts, Beliefs and Recommendations.
Classification systems: are ways of organising our thinking and are often based on Reference models (which reflect best practice). Classifications systems may relate to what we (e.g. be business oriented) or the materials we use (e.g. be technology oriented).
No doubt more sophisticated ways of doing analysis can be applied e.g. that considered but I think we start with a very simple approach is a good place to start:
eg.
- Visions, Strategies, Objectives, Measures, KPIs - can all be recorded as Goals
- Laws, Regulations, Market factors etc. - can all be recorded as Facts
- Causes, Findings, Implication - can all be recorded as Beliefs
- Trends - are either Facts or Beliefs
- Risks and Issues - are the failure to achieve goals now or in the future.
To be useful the relationships between concepts need to be weighted. But the 1st step is to understand the relationships between Goals and Recommendations (via Facts and Beliefs).
When one reads most analysis documents and tries to assemble a model like this - but usually finds large gaps and inconsistencies (which is really just feeble) e.g. the recommendations can be substainiated or the basis of them is not explicit.
This analysis may strategic or tactical, focus on a current problem or future state (visioning), it may be technical or non-technical.
Forcing the thinking into this simple model helps people understand the basis of beliefs and recommendations.
Goals: are things you are trying to achieve. Sometimes technical people also refer to these as principles e.g. non-functional requirements e.g. reliable - but in fact they are goals.
Issues: are problems you are trying to address (they are actually goals stated in a different way)
Facts: are facts i.e. they are not disputable.
Beliefs: should be based on Facts and relate to Goals/Issues (if they don't relate to Goals/Issues they are not that useful)
Recommendations: are actions based on Beliefs to achieve Goals/address Issues.
Concepts: are a grouper for things terms, patterns, principles, ideas we may refer to when we discuss Goals, Facts, Beliefs and Recommendations.
Classification systems: are ways of organising our thinking and are often based on Reference models (which reflect best practice). Classifications systems may relate to what we (e.g. be business oriented) or the materials we use (e.g. be technology oriented).
No doubt more sophisticated ways of doing analysis can be applied e.g. that considered but I think we start with a very simple approach is a good place to start:
eg.
- Visions, Strategies, Objectives, Measures, KPIs - can all be recorded as Goals
- Laws, Regulations, Market factors etc. - can all be recorded as Facts
- Causes, Findings, Implication - can all be recorded as Beliefs
- Trends - are either Facts or Beliefs
- Risks and Issues - are the failure to achieve goals now or in the future.
Sunday, March 1, 2009
Architecture vs Design
The failure to be clear about what we mean by Architecture is associated with a failure to be clear about the design process.
One of the purposes of the strategy & architecture (S&A) is to assist us in supporting the design of business solutions i.e. specific solutions owned by the business that deliver value. The role played by the S&A is one of guiding and constraining the solution, the design process (i.e. the synthetic and creative process) and supporting the evaluation of alternatives (i.e. helping measure how optimal each solution is). In addition it should ideally be used as part of a formal authorisation process.
The design process
Design involves creating an optimised solution based on a set of constraints. When designing technology solutions (including selecting technology products and services) the constraints can be considered to be three major categories i.e. the problem domain, solution domain and strategic domain.
Problem Domain
The problem domain is usually defined by a business case related to the specific business project or owner. This set of constraints may be called the requirements. The business case will usually require a business owner focuses on achieving specific business outcomes. The typically technology solutions will be just one aspect the business owner is considering.
The business owner will usually make clear the desired: business outcome e.g. value creation (or improved outcome by some other measure), time to market etc.; business services or offerings to be provided, supported or enhanced i.e. both their nature and quality; business objects and processes to be supported, enhanced (e.g. automated, streamlined etc.), developed or maintained; business control and governance considerations to be met (e.g. security, regulatory, corporate); business community to serviced; business costs and how return will be achieved i.e. what investment can be made and how the investment can be justified
Solution domain
This relates to what can be created. Our knowledge of the solution domain is based largely on historical knowledge (what we have done, what we know works etc.), our circumstances and the environment (what is available to us) and includes: what we know about how solutions are constructed e.g. best practices, heuristics, patterns; the specific skills, techniques and technical knowledge we have about systems and their operation; the technical assets we have i.e. tools, technology infrastructures (systems, software, hardware), legacies (bespoke and purchased product) and services.
Strategic domain
We can consider a there to be third set of constraints that represents the broader business requirements (i.e. the requirements that represent the sum of all the current future business goals, strategies, projects, initiatives etc.) i.e. beyond the scope of the current project, and beyond the ambit of the immediate business owner. This is what the technology strategy and architecture represents. They can be considered to be in the problem domain (as they are a set of meta-requirements) and the solution domain (to be useful the meta-requirements are usually synthesised so they can be expressed as solution domain constrains). They include: themes and visions; structures and topologies (i.e. high level layout and design); common infrastructures, principles, standards, metrics; transition strategies (i.e. interdependencies roadmaps, constraints etc.).
Often an S&A is reflected in a set of principles that can be combined with other constraints to allow design. Usually some principles are more important to the stakeholder that others (weighting principles in an objective way is very complex and not dealt with in this discussion). In practice decisions are not always made simultaneously (i.e. some decisions precede others) and trhe order in which
decisions are made influence the design.
Getting back to the design process
The process of design can be considered to involve a number of activities (that are undertaken at many levels i.e. recursively, fractaly, iteratively or in parallel). At the highest level we can think of: determining the set of constraints (e.g. requirements gathering), creating a solution by synthesising all of the constraints and imaging possible solutions (design or selection) and evaluation. These steps as different in nature (but intimately connected) i.e.
- first – determine the constraints: is essentially objective (from the designers perspective) i.e. if the business person specifies a requirement it is taken as an objective fact by the designer. It may be a subjective assessment by the business owner providing the requirements i.e. it may, or may not have been objectively determined.
- middle – design synthesis: is non-procedural, inductive, one of synthesis, creative and requires imagination, demands a holistic focus, is intuitive and relies on experience etc. the result from this step is one or more design alternatives or scenarios.
- finally – evaluate design alternatives: involves measurement, assessment, is analytical and should be objective. At major design elaboration or decisions points it makes sense to have a structured and formalised approach. (e.g. our Solution Evaluation Model or SEM). This helps ensure objectivity, transparency and traceability i.e. it helps everyone understand why a design is preferred. This understanding in turn helps educate all parties regarding the implications of specific types of constraints or requirements.
Evaluating the alternatives
A designer may review the constraints and determine a solution they prefer (for what ever reason). Once one is attached to a design there is a tendency to want to move on quickly. While this will often be the correct, and only pragmatic, thing to do (as we rely on intuition, common sense etc.) when major decisions are involved good designers will confirm for themselves that the other alternatives are inferior of the design (or that other constraints that justify their preference need to be articulated).
Alternatively a business person may look at a solution (e.g. a product) and determine it best suits their needs (for what ever reason) i.e. is the optimal solution. Once one is attached to a solution there is also a tendency to want to move on quickly. Again this will often be the correct and pragmatic course of action. But when major decisions are involved most good business people will usually seek confirmation that other alternatives are in fact inferior.
Further items will discuss some of these things in more detail: problem domain, solution domain, principls, patterns (Patterns are generic models that allow one or more design point to be achieved), heuristics and best practices, solution evaluation models.
Considering the longer term
As we are dealing with systems that are undergoing constant change we need to understand why things exist and what problems would exist if we changed what exists. This implies we need an understanding of rationales. It is only by developing this understanding that we can learn, continue to improve the rate that we change and produce better results.
One of the purposes of the strategy & architecture (S&A) is to assist us in supporting the design of business solutions i.e. specific solutions owned by the business that deliver value. The role played by the S&A is one of guiding and constraining the solution, the design process (i.e. the synthetic and creative process) and supporting the evaluation of alternatives (i.e. helping measure how optimal each solution is). In addition it should ideally be used as part of a formal authorisation process.
The design process
Design involves creating an optimised solution based on a set of constraints. When designing technology solutions (including selecting technology products and services) the constraints can be considered to be three major categories i.e. the problem domain, solution domain and strategic domain.
Problem Domain
The problem domain is usually defined by a business case related to the specific business project or owner. This set of constraints may be called the requirements. The business case will usually require a business owner focuses on achieving specific business outcomes. The typically technology solutions will be just one aspect the business owner is considering.
The business owner will usually make clear the desired: business outcome e.g. value creation (or improved outcome by some other measure), time to market etc.; business services or offerings to be provided, supported or enhanced i.e. both their nature and quality; business objects and processes to be supported, enhanced (e.g. automated, streamlined etc.), developed or maintained; business control and governance considerations to be met (e.g. security, regulatory, corporate); business community to serviced; business costs and how return will be achieved i.e. what investment can be made and how the investment can be justified
Solution domain
This relates to what can be created. Our knowledge of the solution domain is based largely on historical knowledge (what we have done, what we know works etc.), our circumstances and the environment (what is available to us) and includes: what we know about how solutions are constructed e.g. best practices, heuristics, patterns; the specific skills, techniques and technical knowledge we have about systems and their operation; the technical assets we have i.e. tools, technology infrastructures (systems, software, hardware), legacies (bespoke and purchased product) and services.
Strategic domain
We can consider a there to be third set of constraints that represents the broader business requirements (i.e. the requirements that represent the sum of all the current future business goals, strategies, projects, initiatives etc.) i.e. beyond the scope of the current project, and beyond the ambit of the immediate business owner. This is what the technology strategy and architecture represents. They can be considered to be in the problem domain (as they are a set of meta-requirements) and the solution domain (to be useful the meta-requirements are usually synthesised so they can be expressed as solution domain constrains). They include: themes and visions; structures and topologies (i.e. high level layout and design); common infrastructures, principles, standards, metrics; transition strategies (i.e. interdependencies roadmaps, constraints etc.).
Often an S&A is reflected in a set of principles that can be combined with other constraints to allow design. Usually some principles are more important to the stakeholder that others (weighting principles in an objective way is very complex and not dealt with in this discussion). In practice decisions are not always made simultaneously (i.e. some decisions precede others) and trhe order in which
decisions are made influence the design.
Getting back to the design process
The process of design can be considered to involve a number of activities (that are undertaken at many levels i.e. recursively, fractaly, iteratively or in parallel). At the highest level we can think of: determining the set of constraints (e.g. requirements gathering), creating a solution by synthesising all of the constraints and imaging possible solutions (design or selection) and evaluation. These steps as different in nature (but intimately connected) i.e.
- first – determine the constraints: is essentially objective (from the designers perspective) i.e. if the business person specifies a requirement it is taken as an objective fact by the designer. It may be a subjective assessment by the business owner providing the requirements i.e. it may, or may not have been objectively determined.
- middle – design synthesis: is non-procedural, inductive, one of synthesis, creative and requires imagination, demands a holistic focus, is intuitive and relies on experience etc. the result from this step is one or more design alternatives or scenarios.
- finally – evaluate design alternatives: involves measurement, assessment, is analytical and should be objective. At major design elaboration or decisions points it makes sense to have a structured and formalised approach. (e.g. our Solution Evaluation Model or SEM). This helps ensure objectivity, transparency and traceability i.e. it helps everyone understand why a design is preferred. This understanding in turn helps educate all parties regarding the implications of specific types of constraints or requirements.
Evaluating the alternatives
A designer may review the constraints and determine a solution they prefer (for what ever reason). Once one is attached to a design there is a tendency to want to move on quickly. While this will often be the correct, and only pragmatic, thing to do (as we rely on intuition, common sense etc.) when major decisions are involved good designers will confirm for themselves that the other alternatives are inferior of the design (or that other constraints that justify their preference need to be articulated).
Alternatively a business person may look at a solution (e.g. a product) and determine it best suits their needs (for what ever reason) i.e. is the optimal solution. Once one is attached to a solution there is also a tendency to want to move on quickly. Again this will often be the correct and pragmatic course of action. But when major decisions are involved most good business people will usually seek confirmation that other alternatives are in fact inferior.
Further items will discuss some of these things in more detail: problem domain, solution domain, principls, patterns (Patterns are generic models that allow one or more design point to be achieved), heuristics and best practices, solution evaluation models.
Considering the longer term
As we are dealing with systems that are undergoing constant change we need to understand why things exist and what problems would exist if we changed what exists. This implies we need an understanding of rationales. It is only by developing this understanding that we can learn, continue to improve the rate that we change and produce better results.
On effective development of strategies
To make strategies effective for all the stakeholders the strategy needs to be able to: evolve dynamically, ensure participations, have clear transparent underlying framework (way of organizing information and making decisions), reflect best practice (learning across the spectrum of sport), allow consensus and divergence of views to be understood, and relate directly to actionable tactics and initiatives.
We can see the failure of strategy when something like the recent economic “melt down” occurs i.e. rather than us being to quickly analysis what the impact of these different externalities logically is on what we need to do – and therefore which programmes and initiatives (i.e. spending) should be adapted and how – business are forced to blind cutting or some extended re-analysis. This is because the knowledge about the exact impact and import of the assumptions the strategies are based and lost in the mists of time.
Working strategies needs to:
Produce Sustained value – This means that we need ensure that information that is captured can related and reused. That it can be refined and changed (the impact of the change or refinement is understood).
Be dynamic and current - The framework (how we do things) needs to be able to evolve dynamically i.e. so that changes we make to how we do things are immediately available. In practice this will mean a systems based solution – as it clear that with even a very small number of documents you can’t effectively (considering time and cost) propagate changes to templates and inter-relationships between the documents.
Ensure participation and engagement - The mechanism for sharing our understanding (i.e. of cause and effect) needs to be accessible – because we need to encourage as broad an engagement / participation as possible. In practice this will mean Web based delivery is important as it removes an inhibitor to engagement. It is at best imprudent to rely on people being able attend face to face meetings.
Be clear, explicit and transparent – We must explicitly define the semantics e.g. we may have goals, facts (including law and regulations, market and environment factors, demographics, etc.), germane beliefs (which should be based on facts and relate to goals i.e. in order to be germane), recommendations (which are based on goals and beliefs). We would also usually want concepts (common terms and concepts), risks (which we may choose to distinguish from risk and issues), extant assets and capabilities identified discretely. If we don’t do this when we disagree on recommendation we can’t even work out what it is we are disagreeing about e.g. the goals, the facts, the beliefs. A weakness with prose based approach both oral and documentary is that frequently the persuasive power lies in eloquence, erudition, wit or charm. These are not really sound ways to make policy. An explicit approach to semantics helps depersonalise things (often disputes arise because of issues of personality and all efforts should be made to avoid this).
The ability to analyse the basis of recommendations (based on agreed beliefs and relate to defined goals) is quite important. To allow effective analysis we need to be to understand the semantics and allowing for weighting i.e. we need to recognize that not all goals are of equal importance and recommendations don’t equally support goals, or follow from beliefs.
Reflect best practice and common - Reference models assist us in organising our thinking. They may be simple classification systems, but ideally they relate high level concepts that allow us to do inferential checks on completeness e.g. to take a trivial example if we have a reference model of services (e.g. “delivery”) and systems (e.g. “delivery tracking system”) and know in this model that “deliveries” must “be tracked” in a “delivery tracking system”. Then when we have a specific thing of service instantiated that is defined as “delivery” - we can infer that their should be a “delivery tracking system” and if nothing of this is instantiated we can infer we have an issue.
Communicate effectively with many stakeholders – we need to show people ONLY what they are interested in seeing. This is why most people won’t read long reports (unless the report is written for them). So what we really need to be able to do is produce a report for audience, from point of view. Traditional documentary approaches to this either result in a plethora of documents oriented at different audiences, on different topics and different levels of detail. Or we end up with a large tome that no wants to read (and very few will).
When we look the above we can see that documents will fail us in this exercise (as will document based Web portals) i.e.
- Sustained value – we can get information related and reused
- Dynamic and current - we can't support a dynamic framework that evolves as we learn and change
- Ensure participation and engagement - we can't ensure engagement. In fact documents will ensure most people don't engage and we can’t build consensus.
- Clear and transparent - we can't be get people to agree what the real issues are (i.e. agreements and disagreements explicit and precise)
- Reflect best practice and common - we can implement a common set of reference models i.e. it is to hard with documents (too much paper).
- We can analyse things - documents need to be read in toto.
We can see the failure of strategy when something like the recent economic “melt down” occurs i.e. rather than us being to quickly analysis what the impact of these different externalities logically is on what we need to do – and therefore which programmes and initiatives (i.e. spending) should be adapted and how – business are forced to blind cutting or some extended re-analysis. This is because the knowledge about the exact impact and import of the assumptions the strategies are based and lost in the mists of time.
Working strategies needs to:
Produce Sustained value – This means that we need ensure that information that is captured can related and reused. That it can be refined and changed (the impact of the change or refinement is understood).
Be dynamic and current - The framework (how we do things) needs to be able to evolve dynamically i.e. so that changes we make to how we do things are immediately available. In practice this will mean a systems based solution – as it clear that with even a very small number of documents you can’t effectively (considering time and cost) propagate changes to templates and inter-relationships between the documents.
Ensure participation and engagement - The mechanism for sharing our understanding (i.e. of cause and effect) needs to be accessible – because we need to encourage as broad an engagement / participation as possible. In practice this will mean Web based delivery is important as it removes an inhibitor to engagement. It is at best imprudent to rely on people being able attend face to face meetings.
Be clear, explicit and transparent – We must explicitly define the semantics e.g. we may have goals, facts (including law and regulations, market and environment factors, demographics, etc.), germane beliefs (which should be based on facts and relate to goals i.e. in order to be germane), recommendations (which are based on goals and beliefs). We would also usually want concepts (common terms and concepts), risks (which we may choose to distinguish from risk and issues), extant assets and capabilities identified discretely. If we don’t do this when we disagree on recommendation we can’t even work out what it is we are disagreeing about e.g. the goals, the facts, the beliefs. A weakness with prose based approach both oral and documentary is that frequently the persuasive power lies in eloquence, erudition, wit or charm. These are not really sound ways to make policy. An explicit approach to semantics helps depersonalise things (often disputes arise because of issues of personality and all efforts should be made to avoid this).
The ability to analyse the basis of recommendations (based on agreed beliefs and relate to defined goals) is quite important. To allow effective analysis we need to be to understand the semantics and allowing for weighting i.e. we need to recognize that not all goals are of equal importance and recommendations don’t equally support goals, or follow from beliefs.
Reflect best practice and common - Reference models assist us in organising our thinking. They may be simple classification systems, but ideally they relate high level concepts that allow us to do inferential checks on completeness e.g. to take a trivial example if we have a reference model of services (e.g. “delivery”) and systems (e.g. “delivery tracking system”) and know in this model that “deliveries” must “be tracked” in a “delivery tracking system”. Then when we have a specific thing of service instantiated that is defined as “delivery” - we can infer that their should be a “delivery tracking system” and if nothing of this is instantiated we can infer we have an issue.
Communicate effectively with many stakeholders – we need to show people ONLY what they are interested in seeing. This is why most people won’t read long reports (unless the report is written for them). So what we really need to be able to do is produce a report for audience, from point of view. Traditional documentary approaches to this either result in a plethora of documents oriented at different audiences, on different topics and different levels of detail. Or we end up with a large tome that no wants to read (and very few will).
When we look the above we can see that documents will fail us in this exercise (as will document based Web portals) i.e.
- Sustained value – we can get information related and reused
- Dynamic and current - we can't support a dynamic framework that evolves as we learn and change
- Ensure participation and engagement - we can't ensure engagement. In fact documents will ensure most people don't engage and we can’t build consensus.
- Clear and transparent - we can't be get people to agree what the real issues are (i.e. agreements and disagreements explicit and precise)
- Reflect best practice and common - we can implement a common set of reference models i.e. it is to hard with documents (too much paper).
- We can analyse things - documents need to be read in toto.
People get hung up on the word "Architecture"
In the inclusion of the word "architecture" in different a set terms seems to lead to some confusion that as the terms share the "A" word that ipso facto they have a lot in common.
People seem to think that the operative word in each of these terms - Enterprise Architect, Systems Architecture, Service Oriented Architecture, Solution Architecture, Infrastructure Architecture - is "Architecture" and this implies some kind of commonality of person, approach, skill set etc. When in fact the orientation is differs considerably and the the focus should be on the non-A word e.g. "Enterprise", "Systems", "Services", "Solution", "Infrastructure".
If we talked about "Designing an Enterprise", "Designing a building", "Designing a car", "Designing a town" - we would not think that per se these activities share a common method, common skills, common tooling. We may recognise that at the highest level there could be some common principles and that lessons could learned, and some techniques transferred, between these - but that would be about as far as we would go.
The "A" word means master builder. Historically a "master" would start as an apprentice, work for many years under a "master" progressively learning what worked and what did not (and developing extensive experience in the domain and materials) - and would eventually become a "master" themselves. Now people seem to disphemistically degrade the "A" by applying it to any design activity.
It seems to me that often the "A" is used to imply an air grandiloquence
People seem to think that the operative word in each of these terms - Enterprise Architect, Systems Architecture, Service Oriented Architecture, Solution Architecture, Infrastructure Architecture - is "Architecture" and this implies some kind of commonality of person, approach, skill set etc. When in fact the orientation is differs considerably and the the focus should be on the non-A word e.g. "Enterprise", "Systems", "Services", "Solution", "Infrastructure".
If we talked about "Designing an Enterprise", "Designing a building", "Designing a car", "Designing a town" - we would not think that per se these activities share a common method, common skills, common tooling. We may recognise that at the highest level there could be some common principles and that lessons could learned, and some techniques transferred, between these - but that would be about as far as we would go.
The "A" word means master builder. Historically a "master" would start as an apprentice, work for many years under a "master" progressively learning what worked and what did not (and developing extensive experience in the domain and materials) - and would eventually become a "master" themselves. Now people seem to disphemistically degrade the "A" by applying it to any design activity.
It seems to me that often the "A" is used to imply an air grandiloquence
Subscribe to:
Posts (Atom)
