Clark Quinn recently asked, as have many others, the difference between collaboration and cooperation, and why it is important. "collaboration means ‘working together’. That’s why you see it in market economies. markets are based on quantity and mass. cooperation means ’sharing’. That’s why you see it in networks. In networks, the nature of the connection is important; it is not simply about quantity and mass … You and I are in a network - but we do not collaborate (we do not align ourselves to the same goal, subscribe to the same vision statement, etc), we *cooperate* - Stephen Downes Cooperation makes more sense as the term to describe working together in a networked and non-directed relationship. This is an important distinction from collaboration. For example, Jérôme Delacroix also sees cooperation as the suitable term for what we do in networks [in French]. Jérôme explains why his site is called Cooperatique and not Collaboratique - collaboration happens around some kind of plan or structure, while cooperation presumes the freedom of individuals to join and participate. He also says that cooperation, not collaboration, is a driver of creativity. It is difficult to be creative while collaborating, because the objective has already been established. Work in networks requires different skills than in directed hierarchies. Cooperation is a foundational behaviour for effectively working in networks, and it’s in networks where most of us, and our children, will be working. Cooperation presumes the freedom of individuals to join and participate. People in networks cannot be told what to do, only influenced through other nodes (people) due to their reputation. If people don’t like you, they won’t connect. In a hierarchy you only have to please your boss. In a network you have to be seen as having some value, though not the same value, by many others. Source: seeking perpetual beta While all levels of complexity exist in our world, more and more of our work deals with real complex problems (in which the relationship between cause and effect can only be perceived in retrospect), whether they be social, technological, or economic. Complex environments and problems are best addressed when we organize as networks, work to continuously develop emergent practices, and cooperate to advance our aspirations. Cooperation is not the same as collaboration, though they are complementary. Teams, groups, and markets collaborate. Online social networks and communities of practice cooperate. Working cooperatively requires a different mindset than merely collaborating on a defined project. Organizations need to extend the notion of work beyond collaboration, beyond teams, and beyond the corporate fire wall. They need to make social networks, communities of practice, and narrative part of the work. It’s a big leap but we need to change the business conversation away from confident military terms (target market, strategic plan, marketing campaign) and instead talk in terms of complexity, wicked problems, and cooperation. Source: seeking perpetual beta We are moving from a market economy to a network economy and the level of complexity is increasing with this hyper-connectedness. Managing in complex adaptive systems means influencing possibilities rather than striving for predictability (good or best practices). Cooperation in our work is needed so that we can continuously develop emergent practices demanded by this complexity. What worked yesterday won’t work today. No one has the definitive answer any more, but we can use the intelligence of our networks to make sense together and see how we can influence desired results. This is cooperation and this is the future, which is already here, albeit unevenly distributed. Shifting the emphasis of work from collaboration, which still is required to get tasks done, to cooperation, in order to thrive in a networked enterprise, means reassessing some of our assumptions and work practices. For instance: The lessening importance of teamwork, versus exploring outside the organization may change our perceptions about being a "team player". Detailed roles and job descriptions are inadequate for work at the edge. Getting rid of individual performance reviews and focusing the performance of the whole organization. One major challenge is that cooperation is much less controllable than our institutions, hierarchies, and HR practices would like to accept. Here is an example from nature. Martin Nowak, a mathematical biologist, concludes The Evolution of Cooperation with the following winning strategy: "What I find very interesting in these games of conditional reciprocity, direct and indirect reciprocity, we can make the point that winning strategies have the following three properties: they must be generous, hopeful and forgiving. Generous in the following sense: if I have a new interaction, now I realize (and this is I think where most people go wrong) that this is not a game where it’s either the other person or me who is winning. Most of our interactions are not like a tennis game in the US Open where one person loses and one person goes to the next round. Most of our interactions are more like let us share the pie and I’m happy to get 49 percent, but the pie is not destroyed. I’m willing to make a deal, and sometimes I accept less than 50 percent. The worst outcome would be to have no deal at all. So in that sense, generous means I never try to get more than the other person. Tit-for-tat never wins in any single encounter; neither does Generous Tit-for-tat. Hopeful is that if there is a new person coming, I start with cooperation. My first move has to be cooperation. If a strategy starts with defection, it’s not a winning strategy. And forgiving, in the sense that if the other person makes a mistake, there must be a mechanism to get over this and to reestablish cooperation." - Martin Nowak This clearly shows how cooperation differs from collaboration. To be generous, hopeful, and forgiving will in the long run make for stronger networks and communities. It works in nature. Cooperation is a necessary behaviour to be open to serendipity and encourage experimentation. Source: adapting to perpetual beta Network societies are mainly cooperative. The rules are no longer clear, as they are in institutions or market economies. When we know who we are working with (suppliers, partners, customers) then collaboration is optimal. But in networks, someone may be our supplier or even our boss one day and our customer the next, so cooperation becomes the best behaviour. In such a society, people can have multiple valences as nodes in many networks at the same time. Successful individuals in a network society will see that their connections change over time, and that openly sharing will make them more valued nodes in the long run. In networks, cooperation is simultaneously altruistic and selfish. We are becoming the global village, described by Marshall McLuhan, and like a tribal village certain aspects of human behaviours that we have ignored for centuries are becoming important as we move into a network society. For instance, there was little privacy in the village, as there seems to be no more privacy today. While we will not repeat the past, there is much we can learn from it. A network society has the potential to extend civil society, while obsolescing hierarchies. It retrieves the cooperation that once existed with kinship, but when pushed to its limits might reverse into the deception of a surveillance society. Cooperation amongst citizens and peers may ensure the latter does not happen. Source: finding perpetual beta

Over the past year, we've implemented some new technologies that will help bring the Learning Ecosystem to life.It also expands the number of applications and technologies that are now available to us.Tools and toys we can use to help create an environment that supports people.Because of the huge increase in complexity, I figured it was time to find a model that could help organize this and bring some structure to what I was trying to do.-------------------I've been playing with the SWAT team over the past year or so, in between work on a major Unified Communications implementation.The SWAT team is trying to bring Enterprise Architecture into our organization.  Planning. Configuration Management. Some knowledge around what we actually have and how we can use it. This has become more important as our organization finds itself tightening its belt.The old "Shiny thing, must buy" approach is (finally) being questioned.(Yay!)-------------------- The SWAT team boss, invited me to join his team for TOGAF 9 certification. TOGAF is an open source enterprise architecture methodology and framework that seems to be increasingly popular.Some things I liked about this model:The emphasis on the business processIt has a well-defined series of steps / phasesThe open source community has already developed templates and models we can use in each step It accommodates project management and service delivery models in a really tidy way (vs just focusing on one aspect of work life)A number of IT departments are using this....so as educators, we are beginning to speak the same "language" as our IT folks.It is built to solve the problem I have - accommodating a mess of stuff into one organized architecture that I can plan against.So with shiny new cert in hand (yay me!), I am in the process of restructuring the ecosystem to fit this new model.Around the regular parts of my job, of course.....And with the usual limited resources + healthy skepticism of a large portion of my org.Guerrilla change management...again.

Please note that this overview is absolutely NOT a replacement for reading the materials or taking a certification course.Open Group - TOGAF documentation and white papersAn Introduction to TOGAF 9.1 - free pdfAny comments about TOGAF in this blog are my personal opinion, understanding and application.I will be linking to appropriate pictures so you can see the source material. ------------------One of the things I like about TOGAF is that it deals in layers - from general to specific.Here is the general picture of the framework.Our definitions:Enterprise Strategic Architecture - all of the IT systems in our organization, including contracted cloud solutions.  Our learning ecosystem is meant to mesh in with this greater Enterprise layer as much as possible. From the beginning, one of the key tenants of the ecosystem was to integrate and mesh with the greater environment as much as possible.  Because this is where people spend most of their time working.  At least in my world.  And I'm in higher ed.  My audience doesn't do their day-to-day work in the LMS. At least last I checked.It is also (in my mind) a win-win for both the educators and IT.  We get the tools we need to do our business quickly, the enterprise maximizes their IT investment, and it is much easier for the IT group to support us. Segment Architecture (we are here) - for the purpose of the Learning Ecosystem, we are dividing this segment based on function. "Is it used for executing 'learning' stuff?" This level will help define the interconnections between the various applications and tools we use in practice. In this layer, we are looking at start-to-finish workflows, the tools we use to execute those workflows, and how everything inter-relates.  It's the "Program Management" layer - with "Learning Technologies" as the program.When we are talking about start-to-finish workflows, we are not only talking about the technologies.  We are talking about what people are doing. Handoffs.  Choices and exceptions.  How people actually do their work.  In any of these methodologies driven by technologists, despite the best of intentions by the designers....application tends to be technology focused.  Less messy.  I'm trying not to fall into that trap.Capability Layer - for the purpose of the Learning Ecosystem, this is the individual piece. For instance, SkillPort LMS would be a Capability layer.  All of the information about SkillPort (direct connections in and out, contracts, workflows, etc) would be within that specific capability.  Another capability layer would be set up for WebEx.  Another for the training portal we are developing using SharePoint.  Another for classroom registration. Another for instructional design....The capability layers should NOT be limited to technology and the technologies we use.  We're trying to get a clear picture of all of our activities so we can plan a strategy and make decisions. The first challenge, for me, is going to be making sure I have all of the capabilities defined in a way that captures everything that should be in the Learning Ecosystem and that makes sense to people.I'll be sharing these as I get these layers more tightly defined.

In TOGAF (The Open Group Architecture Forum) terms - this is the Architectural Development Model (ADM).  Because acronyms are awesome.Please go to Introduction to the ADM and scroll down to section 5.2.2 for the official explanation and definitions.These are mine (with apologies to the Open Group)Preliminary - "What do I have lying around?"  Our organization is here.Requirements - "What do people want this thing to do".  Lots and lots of levels to this.  I'm in the process of gathering 7 years worth of stories and figuring out how to build a requirements library.A - Architecture Vision - "What is the high-level architecture and, roughly, how do we want this to evolve?"  Don't worry - the next few phases will nail this down.B - Business Architecture - Nailing down processes and workflows.  What people actually do.  "How do we want to improve the process?"  Note: This piece SHOULD guide the other architectures.  However, B, C and D are often developed in parallel in practice.C - Information Systems Architecture - This is all of the tools that you use to perform your processes. The model breaks it down even further into Application architecture and Data Architecture.Application architecture focuses on what tools you use. The Data architecture focuses on what information goes in and out of the applications and where it goes.  Don't neglect the Data architecture. We will need this for reporting later.  You are doing reporting, aren't you?D - Technology Architecture - This is the servers and network etc. Making friends with your IT department will be key.  You know...in case they move a server your LMS is housed into the cloud.  Because there are other, non-technological ramifications to this action. Like having your user interfaces change on you without warning.  Or if they are having a maintenance outage that suddenly prohibits access to your webinar tool on the day you are presenting to 100 people. So it is good to have at least a rough idea of the technology architecture of your applications.E - Opportunities and Solutions - This is where we nail down where we want to go.  What we want our future state to look like.F - Migration Planning - This is where we plan how we are going to get there.  Which projects, what order, who we need to help us, that sort of thing.G - Implementation Governance - "Git'r Done". Making real.H - Architecture Change Management - Did we actually get there?  What worked? What didn't? What needs to change in the architecture plan? Where do we want to go next?  For those of us versed in ADDIE - this is the "Evaluation" piece.As we were warned in our certification training - the first go-around through the cycle is the toughest.  Because all of the stuff is spread out and disorganized and housed in people's heads.Our organization is using the Learning Ecosystem as a smaller scale way to start hashing through this cycle.  Mostly because I am motivated to actually use this thing I learned - at least for my own needs, even if few other people find it useful. And I think it is "low profile" enough to allow the SWAT team and I to experiment with some things around how this might operate on a larger scale.

This is the official description of how the Preliminary Stage works.This is what this phase feels like.....---------------------In my spare time (around projects and the job I am supposed to be doing), I am gathering all the things.The tools and applications we have lying around the shop - both stuff we currently use and stuff that may prove useful laterRequirements and stories from 7 years at this organizationOutside stories from my peers I may find useful (otherwise known as "best practices")Old project notesDocumentationModelsTemplatesOrganizational processes we need to work withinFor service delivery - we use ITIL to organize ourselvesFor project management - we use PMBOKContracts processes Procurement processesIntake processesDocument it even if you think you won't need it.  Chances are, it will pop up later when you actually threaten to do something.Stakeholders - including how supportive they are and how much they can hurt you.This, you might want to keep very separate from the other documentation.Organizational and environmental driversAny sacred cows - you DEFINITELY want to identify these. A lot of resistance will pop up from here.Below is a 3 minute video containing a brief demonstration of how we are starting to organize stuff.We're using SharePoint.

- From the Happy Medic. This is a lot more glamorous than preventing the fire in the first place.-------------------------- Resistance.  I've seen this over too many years and too many organizations.People nod their heads and go "Yes - planning is a great idea!  We should have a strategy!  This will help us make better decisions! We can save money! (etc)"And then they do everything they can to prevent it from happening.Why?Lack of "flexibility" - they can't just up and do what they want once there is a plan in place. Not that this was ever true, but before they could feign ignorance if things don't work out.The need to start saying "no" and set boundaries - a perceived political handicap for those whose entire career success is based on making people (especially higher-ups) "feel good".The fear of uncovering something they don't want uncovered - ANY of these planning / organization / architecture projects run the risk of uncovering some skeletons.Processes not "working" the way they are supposed to (and the resulting "surprise")People using the lack of transparency to serve their own purposesThe assumption that "knowledge is power" without understanding that knowledge is more powerful when shared.Even worse - when you are doing this within a culture that often actively punishes sharing.  Even if the touted "values" state otherwise.The activities of planning don't look like actual work.Or worse, too many instances of planning being done in replacement of actual work.  This happens enough times and any organization is going to get a bit cynical. Prevention isn't nearly as glamorous-looking as fire-fightingPeople love rescuers.  It just sucks when the problem could have been prevented in the first place.It's hard to prove your worth by showing what DIDN'T happen and preventing problems.  It's much easier to show the problems (that manifested) that you DID solve.   Irregardless of whether it was a self-created or preventable problem. As expected, as soon as real activity towards an architecture started happening, we started seeing resistance.----------------------Right now, the only mitigation strategy I have is to couch my activities in terms of "personal organization."  Small scale, low profile, low resource need. As long as I don't neglect my current primary responsibilities and don't ask for much, I should be OK.   Worst case scenario - I've learned something as a result of these efforts and have made some valuable changes to my portfolio that I can leverage in the future.

Establishing the principles behind the ecosystem was the first step in developing Ecosystem 1.0.Having these principles available lets me take advantage of opportunities while I attempt to organize everything into the new TOGAF-based architecture.It's even more important when working in an organization that does not particularly value the act of planning.  You still need to show progress and activity.  Creating a Visio flowchart or a Requirements matrix doesn't really count.I also need some critical success factors to measure against. The world won't stand still while I get my act together.The principles I am moving forward with:- As needed performance support- Continuous professional developmentCritical success factors:- Visibility - can people find the training they need?- Communication - do people know what they need?- Tracking - do people know how they are doing?The Ecosystem is at a point where I need to re-establish relationships with the stakeholder community (there have been a number of changes) and validate whether we want to maintain these particular principles and critical success factors.Unfortunately, the primary stakeholders and supporters within my division have other priorities right now.  So I am going to move forward with this until the timing and environment improves.  At least this gives me a foundation to work with.

Our Enterprise SWAT Team Lead has started an Innovation Forum within our division.During one of the forums, our HR Client Partner at the time asked about ways we can create a training page for our Division.This has been on my mind since the inception of Ecosystem 1.0.Opportunity knocks....-----------------As we discussed in the previous post, just because we are busy planning doesn't mean the world stands still.The SWAT Team Lead, the HR Client Partner and I (with the blessing of the Deputy Muck)  spent a month putting together a training portal through our SharePoint site.Beyond providing a page that combines all of the training resources available to our division, we are also using this as a prototype for a University-wide training portal.  This is also a way for us to rapidly prototype this idea within SharePoint.  See what works and what doesn't.A few notes:We opened this to view-only for the entire organization.We will likely isolate some permissions for things that are Division-only, but this is a start  Edit permissions are available to the Division.  We are going on the assumption of trust.We are currently using documents and links to the documents as the structure for the curriculum.  Depending on how the interfaces with other groups go, this might change to the Wiki features or a SharePoint add-onThere is currently no tracking or reporting attached to any of this outside of whatever is native to SharePoint.  This means, no completion records.  Again, this might change if the organization determines that it is a requirement.  Right now, it's not on the priority list.  Specifically reportable items are accessed through the LMS.The 7 minute video below provides a walkthrough of the portal.Hope this helps. Comments welcome.

From Techfellows - University of Alaska Anchorage.--------------------------- As I put together the architecture, I have to decide whether my efforts are going to be present-focused (ie. capturing the current baseline) or future-focused (ie. documenting where I want to be - also known as Target First).Unless you work for an organization that has clear, centralized configuration management and everyone (you, your IT group, the stakeholders) has a solid understanding of the current architecture, chances are you will be documenting Baseline first.This is a really good exercise.  I personally find it hard to do any system improvement if I don't know what the system is in the first place.  Not that I haven't tried....-----------------------There are three main "architectures" I will be documenting during the course of this process.The Business Architecture (Stage B) - ie What people do.  Focused on what they REALLY do vs. what we THINK they SHOULD be doing. Warning: Danger lurks here.The Application Architecture (Stage C) - ie What tools we use.The Data Architecture (also Stage C) - ie What we are trying to get out of it and where that information is housed.So what about the Technology Architecture (Stage D) you ask? Chances are, your team (talking to mostly trainers and educators etc) is not responsible for the infrastructure of your tools (servers, the network, whether or not it is in "the cloud"etc).This will be a good opportunity to make friends with your IT folks who have knowledge of these things. We'll talk about the questions to ask later....--------------------------As you'll notice throughout this series, I am doing a number of these phases in parallel vs. in the correct "order".  Again - taking advantage of opportunities as they present themselves.Besides, there is nothing in the TOGAF manual that says I HAVE to do things in order.And anyway, so much of this process for me is a "fact-finding" mission to see what we have and what we are working with.My goals for this process are:Figure out what is lying aroundDetermine how to optimize what is lying aroundIdentify gaps in functionality (and, ideally, avoid duplication)Identify knowledge gaps and fill them Identify stakeholder gaps - now is a good time to do the "people work" to minimize political surprises later.Share what I've learned with the organization.  Put TOGAF through its paces to see what works. None of us have really done this before.  And the best way I learn something is by doing it.  And if I have something concrete - I can see what modifications need to be made.

From lynda-m at Deviantart.com ---------------------------------------- The Preliminary Phase of the architecture is supposed to have 4 outputs.  I am outlining these below to help provide a checklist of the types of information I need to gather and some of the early decisions that need to be considered.---------------------------------------The Organizational Model for the Architecture provides a rough idea of what you have to work with:People Who is impactedWho we need to target for governance and decision-making around the architectureWhat roles these people play - I'm going to include support hereStuffWhat we haveWhat we don't haveConstraints around what we can do to fill the gapsHow much money we might need (though I am going into this assuming there will be NO money)Usually - there would also be an assessment of architectural maturity. The answer for us is "non-existent and the gap is huge and I may have potentially bitten off more than I can chew, but it's worth a shot....."---------------------------------- There is also a Tailored Architecture Framework.  In this will be:What method I am using (deciding to use TOGAF. There's other methods)What other methods for activities need to be used to align with the organization (I'm sure more will appear as I work on this)Service Management - ITILProject Management - PMBOKRequirements Management - tbd.  Could be BABOK or Volare or something elseTemplates for deliverablesArchitecture principlesThe Initial Repository (where I'm storing stuff)Other tools I should be using.  Flowcharts - Visio, planning to use Archimate modelingMS OfficeAnything else that may come up that will help me communicate to others--------------------------------- There would also be a Request for Architecture Work created by a sponsor. This document would contain high-level information on the following:SponsorsMission statement for the architectureBusiness goals to be addressed by the architectureStrategic plans for the businessTime limitsChanges and challenges in the business environment triggering this architectureConstraints - internal and externalBudget constraints and informationCurrent business system descriptionCurrent IT system architecture descriptionDescription of the developing organization and the resources availableI may still write one of these up.  More for my own reference and to serve as a template if I am able to get a sponsor that's not me.---------------------------The Architecture Definition Document defines what this architecture / ecosystem IS.This will be written after the other three documents are at least in draft form.Scope of the architecture - in my case, "Learning / Teaching activities" Goals, objectives and constraints for the architecture.  This would be defined in the Request for Architecture work.Architecture principles - how I'm basing decisions for the Target (future-state) architectureBaseline architectureThe architecture models, for each iteration of the future stateThe rationale and justification for the approach -why I'm using TOGAF instead of Zachman or some other architecture modelThe mapping of the Architecture Repository - where it is, table of contents, how to categorize stuff, how to find stuffGap analysis - what needs to happen to go from point A to point BImpact assessment - what we think will happen if we manage to be successful--------------------------None of these documents will be final at this point.I personally see it as more of a checklist....Do I have everything I need to answer these questions? Have I thought of everything that may apply to the architecture?Is the definition of my scope accurate and clearly delineated?