three posts for digitization of oceans reference architecture

The next three posts within my series describing the need for a digitization of oceans reference architecture will be focused on the three technology domains of; end-points, communications, and data stores. This separation is to allow a deeper look into each domain as they have different considerations in relation to technology architecture and attributes important to the digitization of oceans.

End Points: the sensors and devices which collect and emit data. Consider this the Internet of Things (IoT) that can be located anywhere within and around oceans, airborne, surface, and submersible.

https://en.wikipedia.org/wiki/User:Peterrawsthorne/Digitization_of_Oceans#End_Points

Communications: the communications technologies available to transfer data from one place to another. A lot to explore within this domain; as underwater data transmission is an emerging technology, and the structure of the data messages will become the foundation of the reference architecture.

https://en.wikipedia.org/wiki/User:Peterrawsthorne/Digitization_of_Oceans#Communications

Data Stores: there are many existing data storage approaches, locations, and structures that can be used to store the oceans data. Databases and database designs are already available for many of the subjects within the digitization of oceans. Better to use exiting methods to store the structured and unstructured data and use a federated approach to bring them together.

https://en.wikipedia.org/wiki/User:Peterrawsthorne/Digitization_of_Oceans#Data_Stores

Creating an inventory
The number of technologies, vendors, standards, and approaches within these three domains will be large and forever growing. To start documenting this inventory I have created a Wikipedia page under my Wikipedia account. Once this page describing the Digitization of Oceans and its Reference Architecture is more complete I will submit it as a published article otherwise consider it a work in progress. Feel free to join in and edit the work in progress wiki page;

https://en.wikipedia.org/wiki/User:Peterrawsthorne/Digitization_of_Oceans#Lists

What is a reference architecture?

There are many descriptions of reference architectures available on the web. Here is a list of some I consider do a good job of describing the subject while supporting the description I am working  toward in the digitization of oceans;

1. Reference Architecture: The best of best practices - given its age (published 2002) it is still relevant and pragmatic. Though I do consider the description too dependent upon RUP, which introduces many weighty practices and misses some of the more agile and emergent approaches. Still the description gives good detail to the importance, breadth, and depth of the reference architecture. The later sections of this description provide information on creating, using, updating, and working with a reference architecture. These sections are particularly useful in developing the digitization of oceans reference architecture. I strongly believe the oceans reference architecture will be emergent as many new technologies and stakeholders contribute and become a part of developing the architecture.
   

   Emergent architecture is when organizational structures such as business processes and technologies are designed incrementally by many designers.

2. Wikipedia: Reference Architecture - very short for a complex topic, but it is too the point in defining the reference architecture as templates within a subject, industry, or domain. It stresses the importance of a common vocabulary and in drawing upon successful projects within the domain. It aligns with the use of APIs which I believe will become an important part of a strong digitization of oceans reference architecture.  It also calls out a number of the benefits derived from the reference architecture.
   
   
3. CIO Online Magazine - describes where the reference architecture fits within the EA toolkit, and looks to all the relationships among business, systems, and technology. It describes how the reference architecture can greatly assist in defining specific technical deliverables within these complex systems. Having a proven, standards based, and shared toolkit for developing the oceans reference architecture will assist in keeping the architecture team distributed throughout Atlantic Canada well aligned when creating and maintaining the reference architecture..

Some example reference architectures:

1. Microsoft Industry Reference Architecture for Banking (MIRA-B)
2. A Reference Architecture for The Open Banking Standard
3. IBM Insurance Reference Architecture
4. Healthcare Reference Architecture

These four serve as examples of reference architectures from established industries where the patterns, technologies, and architectures have developed through time. As you read through these you can get a sense of the value, industry collaboration, growth, and innovation that can be facilitated by having a comprehensive industry reference architecture.

What is unique about a digitization of oceans reference architecture?

The infrastructure of the Digital Ocean. (Courtesy of Liquid Robotics, a Boeing Company)

It's too early in this discussion to be specific about the oceans reference architecture, it is important to note that it is both broad and deep. It is broad in that it includes many ground based systems, processes, and infrastructure similar in complexity to the previously mentioned examples. In addition to this broadness we need to add the theater in which the digitization of oceans operates; we have vessels of many types (airborne, surface, and submersible), we have a growing collection of sensors and protocols, we have cross industry collaborations (fisheries, environment, oil and gas, shipping, researchers, academia, defense, etc.). I believe it is safe to say the reference architecture for the digitization of oceans will be very broad due to the number of data collection points and the number of intersections (technical and otherwise). The oceans reference architecture will also be very deep in that the data will be coming from many sources above and below the ocean surface. And the data that is being collected will both be very specific and detailed, while also being general at a more meta level. I believe it is the breadth and depth of the digitization of oceans that make its reference architecture unique. And its creation is a large, important, and emerging challenge... more on this to come.

Over the next few months I will be publishing a series of blog posts describing, in more detail, all the aspects for building a successful digitization of oceans reference architecture. Next up is; "a plethora of end points" with focus on oceans technology and the Internet of Things (IoT). Please follow along and make comment. For a table of contents of these coming posts please review a companion post; Digitization of Oceans Reference Architecture TOC

Digitization of Oceans Reference Architecture TOC

For a sense of where I am going with this series of posts describing a reference architecture for the digitization of oceans, please consider this "table of contents". As I complete items in the list, I will update this TOC;

1. Introduction - summary of why a series of posts describing a digitization of oceans reference architecture.
2. What is a reference architecture? - summary of the existing online descriptions of reference architecture and why it is important to building a strong technology ecosystem.
3. A plethora of end points - with new Internet of Things (IoT) end points coming available with increasing frequency we look to how many sensor types are available to an oceans reference architecture and some examples of how they are being used. I've included a couple more posts describing end points, as I deepened my research I felt the descriptions needs to be expanded to include what is happening as end-points in the oceans and in the air.
• Oceans end-points
• Airborne end-points
4. Communications - description of the current state of data communications above and below the oceans surface. And why it matters to the reference architecture.
5. Messaging Standards - the structure of the data packages (or messages) between the endpoints is a very important attribute of a successful reference architecture.
6. What is the digitization of oceans? - a high level description of the digitization of oceans. This will detail the breadth and depth of what is considered the digitization of oceans. This description should also consider the intersection of the different ecosystems of; business, innovation, and knowledge.
7. What is a digitization of oceans reference architecture? - comprehensive diagram of the entities within the oceans reference architecture with detailed description of each item and their connections (digital or otherwise).
8. The importance of good governance - the dynamic nature of innovation within the digitization of oceans will cause many elements of the reference architecture to be changing. To encourage interoperability at all levels (technical and otherwise) having good governance will be paramount for success.
9. The economic value to be found in the oceans reference architecture - why is a reference architecture valuable for community, business, innovation, etc. And why Atlantic Canada should be a major contributor or primary steward of the reference architecture.
10. How to create the digitization of oceans reference architecture - what is the road map in completing the first release of a digitization of oceans reference architecture. I purposely say first release as this reference architecture will need constant tending as new technologies and capabilities come available.

Keep in mind this is meant to kick off a conversation about creating a reference architecture for the digitization of oceans. This is NOT something I want to do on my own, or believe I could do effectively on my own without contributions from others and a few years of focused effort. I really want engagement across Atlantic Canada to discuss the idea of creating this reference architecture and to become stewards of the reference architecture as it is used globally for the benefit of everybody.

Disclaimer - All views expressed on this site are my own and do not represent the opinions of any entity whatsoever with which I have been, am now, or will be affiliated. They are views created by my many years as an IT professional and, more importantly, an enterprise architect responsible for building large and distributed systems.

Reference architecture for the digitization of oceans

I strongly believe one of the cornerstones for the successful digitization of oceans is a reference architecture. I believe this also holds true for the digitization of oil and gas, but I see this digitization as a subset of the oceans. Or more specifically, I see the digitization of maritime oil and gas as a subset of the digitization of oceans. I regress... One of the most important aspects of the reference architecture is its openness (as opposed to proprietary). If we are wanting to spur innovation in Atlantic Canada we need every small, medium, and large organization to realize benefit from shared digital resources. We need a way for all these organizations to openly communicate and build this digital ecosystem. The digitization of oceans reference architecture will define (or utilize existing approaches) the "language" that all oceans technologies communicate with one another and remember their collective history.

An example; the reference architecture would specify the digital messaging structure for an ocean temperature event. Therefore, when a small startup (that specializes in ocean temperature sensors) needs to publish their data they need only comply with messaging structures for ocean temperature. This would allow everyone in the ecosystem to get at their temperature event data as soon as it is available. Also important, is the startups market for ocean temperature sensors customers includes everyone who is aligned with the oceans reference architecture and it's messaging structures.

Another example; the reference architecture would specify the underwater wireless communications approaches and suggested protocols and practices. All allowing the temperature event data to be broadcast and communicated to the historical repository for archiving.

Another example; the reference architecture would specify all the messaging structures and the data storage approaches so the data could be archived and be available through time. The historical archive would allow for retrieval, searching, research, planning, and analysis.

Over the next few months I will be publishing a series of blog posts describing, in more detail, all the aspects for building a successful digitization of oceans reference architecture. Next up is; "what is a reference architecture" with focus on oceans technology. Please follow along and make comment. For a table of contents of these coming posts please review a companion post; Digitization of Oceans Reference Architecture TOC

Disclaimer - All views expressed on this site are my own and do not represent the opinions of any entity whatsoever with which I have been, am now, or will be affiliated. They are views created by my many years as an IT professional and, more importantly, an enterprise architect responsible for building large and distributed systems.

ACAITA Inaugural Meeting St. John's

Three architecturally minded technical professionals got together at the Ship Public House to share a couple of beers, tell a few technical project yarns, and enjoy some traditional music. The conversation was also very candid and at times could have been considered cynical. But... from all this emerged some optimism and some healthy and solid work we can do to support and encourage the growth of technology architecture practices in Newfoundland and the whole of Atlantic Canada.

We all agreed it's a challenging time in Newfoundland. The economy is in decline, the population is aging, the young and up-n-comers are leaving, and the current government is overly focused on the immediate need to get the provincial house in order. So when a few architects and senior software developers get together our pragmatism gets the better of us and we trend toward being pessimistic about the senior technical opportunities available in Newfoundland. We also identified a handful of activities to be optimistic about;

• St. John's has a growing startup ecosystem - this didn't exist 5 - 7 years ago and now it has a physical space (common ground), a few small and growing technology companies, and s small group of committed people who want to see technology startups thrive in Newfoundland.
• A technology industry association (NATI) which is committed, effective, and strongly resourced toward building success for the province (and Atlantic Canada as a whole).
• Strongly positioned for the digitization of two or three industry sectors (Oil and Gas, Fisheries, Arctic Environments). Newfoundland, if it put its mind too it, could be at the table in a big way for the digitization of any of these three industry sectors.
• Our current federal government is committed to encouraging innovation and in supporting collaborative initiatives that fall well within the digitization of oceans and ocean technology.

We all agreed that participating in the local technology community is important, and we get enjoyment from sharing our technical experiences and understanding other technology project current within St. John's. Having a strong and growing technology architecture community would help in building the local technology economy and opportunities.

A focused economic sector

Recently I have been working toward growing the Atlantic Canada Association of Information Technology Architects (ACAITA). The idea of creating this group got a lot of support and quickly had 90 members representing all four Atlantic Canadian provinces. A few weeks back a group of us got together in Halifax to discuss the association, its purpose, its road ahead, and other things architectural. I believe for this association to be successful it needs to bring value to its members and to the business communities in which it exists.

Differing ecosystems should work together to progress a focused economic sector.

Over the last few weeks I have had informal conversations with a number of intelligent and supportive people who work for ACOA, NATI, and Industry. I want to provide many thanks to these organizations and their representatives for taking the time and providing insight into how best to build the ACAITA. The subjects we discussed are focused upon growing the association and how best to engage the business community. I also believe that my knowledge as an EA combined with recent research activities around business ecosystem modeling and reference architectures had an influence over the directions these conversations took. Described below are the highlights to these conversations;

1. ACOA - Atlantic Canada Opportunities Agency
   
   • The ACAITA needs to define itself and have a comprehensive set of demographic data. Not only we need to know how many members we have and which province they are located, we need to know the total number of architects in the Atlantic provinces, where their focus is, what industries they work, etc.
   • Reach out to industry / business and find out exactly what their architectural needs are and where they see gaps in the workforce or capability.
   • The Oil and Gas sector remains strong for Newfoundland and Labrador and providing architectural support here should be considered a pillar for ACAITA. Becoming champions of the Oil and Gas Reference Architecture could be one of the associations cornerstones.
   • Keeping things Atlantic would support the ACAITA mission. Identify all the main business ecosystems and reference architectures where Atlantic Canada could become internationally recognized would be a solid approach. 
2. NATI - Newfoundland and Labrador Association of Technology Industries
   
   • Having ACAITA as a pan-Atlantic organization remains as a very good idea. And looking for NATI equivalents in all the other three provinces would help in getting ACAITA support.
   • From a Technology Industries perspective the Digitization of Oil and Gas is capturing increasing attention and the investments made here should have derived benefit for Atlantic Canada outside Oil and Gas for the near and long terms.
   • NL already has many technology companies within the Oil and Gas sector and identifying all the organizational ecosystems and intrinsic reference architectures would help support ACAITA success and growth.
   • Its important that NL grows technology and digitization capabilities outside of Oil and Gas. And an Association like ACAITA would fit well with growing this derived capabilities perspective.
3. Industry - conversations with assorted industry professionals
   
   • Confirmed the focus of Oil and Gas for NL and that growing the architectural capabilities supporting these industries in the province of NL would assist greatly.
   • Mapping out the ecosystems (business, innovation, and knowledge) supported by the intrinsic reference architectures could further pull everything together, It could provide a technology foundation in which to build the Digitization of Oil and Gas. An expertise which NL should own internationally.

The Conclusion
Identify the main industry sectors with Atlantic Canada and begin ecosystem mapping with an eye to defining the intrinsic reference architectures. Engage both IT Architects and organizations (business, innovation, and knowledge) to define and publish documents describing ecosystems and reference architectures.

ACAITA Partnership Recommendation

There are a number of groups, professional associations, organizations involved with developing and forwarding the practice of IT architecture. The ones I see relevant to developing an IT Architecture association are as follows;

1. IASA - An association for all IT Architects
2. OpenGroup - Vendor neutral IT standards and certifications
3. AEA - Association of Enterprise Architects
4. EACOE - Enterprise Architecture Centre of Excellence
5. FEAC - Training and Certification Institution for Enterprise Architects
6. ISC - Vendor-neutral education products, career services, and Gold Standard credentials to professionals.
7. CIPS - Canada's association of Information Technology (IT) professionals
8. BAG - Business Architecture Guild 

I believe any of these have valuable resources that could support, and be useful to, the ACAITA membership. I believe the IASA provides the broadest view into architecture, where the other organizations are more focused on an area of architecture, such as; security, business, the enterprise, or IT in general.

I recommend the ACAITA aligns itself with two or three of these groups / associations as determined by the resources they can make available toward growing the architectural capabilities of Atlantic Canadians. To start, I believe a few of us should consider becoming full members of the IASA Canada chapter with the intention to form the Atlantic Canada chapter. I also recommend we align ourselves with one or two of the training and certification groups... I believe this can wait until we have our association alignment.

ACAITA Inaugural meeting Halifax

We had an outstanding inaugural meeting of the Atlantic Canada Association of Information Technology Architects (ACAITA). Seven Halifax members (and one ST. John's member) came out to the 2nd Floor of the Lower Deck to share some nachos, some great conversation about the state of Enterprise Architecture (and beyond), and to share a few beers. It was so great to meet like minded technical people who are very interested in talking about IT Architecture. I enjoyed the conversation, as it was as broad as it was deep. I'll summarize what I took from the evening in three main themes;

The Highlights

These are what I consider the highlights of the discussion. It may have been different for other participants, this is what stood out for me.

• Attracting Diversity - we need diversity in the group! It would make the group stronger, more resilient to changes, and help it last beyond one or two peoples efforts. When we talked diversity it mostly focused on a good spread of ages and experience and how there was much that could be shared to bring younger IT people into the architect roles. The diversity also included discussion from the broader sense of gender and ethnic / cultural background. In the end, it was mostly focused on age and experience and including as much diversity as we could.
• Atlantic Canadian Architects are well prepared - the Atlantic Canada market is smaller for IT Architects, and yet, the responsibilities and opportunities are not specialized, the IT Architects in Atlantic Canada have therefore developed broad experience. In other words, they have filled many of the Architectural roles because the work needed to get done and they were the most appropriate to get it done. This is a real strength for IT Architects in Atlantic Canada. To be a good Architect you need to see the big picture and having a wide range of experience is essential.
• Remain Technology Agnostic - we agreed that it is best to remain technology agnostic. This means we never align ourselves with a particular vendor, framework, approach, methodology, partner, certification, training, etc. This means that we encourage discussion about everything architectural and how different technologies and approaches work together and the best way to get something done. This means we encourage involvement from all vendors, frameworks, methodologies, etc... in the end, deepening our understanding of how to work with all vendors products, methodologies, frameworks, etc... is best for everyone. 

The Summary

In addition to the highlights there are other discussion themes worth mentioning

• We have a good number of very experienced Architects in Atlantic Canada who have worked internationally and across all the different architectural disciplines. When you consider our associations vision to become internationally known for our architectural abilities we already have a very solid foundation.

  

  The many roles of the IT Architect.

• These kinds of groups / associations have come and gone over the past 30 years and it is a good idea to start meeting again. There is great value both for the profession and for the technology industries in Atlantic Canada. Mostly, its having other architects to discuss how to best get things done and to deepen understanding of emerging technologies. We also need to reach out to the younger IT professionals to be sure the IT Architecture within Atlantic Canada stays strong and healthy. 
• Having this as an Atlantic Canada initiative is a really good idea. This mostly comes from Atlantic Canada being a relatively small market and many IT professionals know one another. It is also well aligned with how many public and private organizations function within Atlantic Canada. When wanting to partner and get support from these organizations it is important that we span all four Atlantic provinces so we can reduce duplication of effort and have broader impact in all we do.

The Next Steps

• Get together often, formally and informally - yes, it is a good idea to have formalized meetings and events, but it is also a good idea to get together informally for Lunch, or a game of pool, and just talk architecture. We agreed we need as many informal meetings as formal meetings.
• Use the #ACAITA hashtag - whenever you post or use online networks / media use the #ACAITA hashtag. This hashtag will assist in bringing the communities online discussion together and followed. 
• Attend all kinds of events as a ACAITA member - discussing architecture (as a member of the ACAITA) at the many technology and other events will bring our association more attention. Good IT architecture is needed wherever a technology initiative is underway. Get involved, reach out, talk architecture.
• Identify all the IT Architecture and related education programs in Atlantic Canada - we agreed it would be very useful to gather a list of as many of the computer science, technology and business programs that wouldbe interested in IT architecture.
• Identify the Architectural Groups we could consider partnering - we also need to consider all the existing associations that would be useful to align ourselves. This could be of great assistance to our collective success, but also save us a lot of time and effort by learning from those who have gone before us.

A bold vision for Atlantic Canada Association of IT Architects

I had a bit of an epiphany when thinking about the purpose of the Atlantic Canada Association of IT Architects. I was thinking about to things;

1. What is going to attract membership to share with, and access, the association.
2. How are we going to engage public and private sector organizations is a meaningful way.

My thinking ended up rewriting the vision statement for the organization to be much more bold and broad. I changed the vision to be;

Our Vision is for Atlantic Canada to become world renowned for our Information Technology Architectural excellence. This excellence will support, and be a pillar for, the technology sector economy within all four provinces of Atlantic Canada. Overall the ACAITA will increase the awareness, effectiveness, and value of Information Technology Architecture for practitioners and organizations. Atlantic Canada will be recognized worldwide for its Architectural excellence and effectiveness.

The rational for this altered vision is to attract members and engage the sector. More specifically, I believe the following themes are important when wanting to fulfill these two key aspects of building an association (and community).

• We need a massive way to inspire people to become members, and to contribute. Even though there is already a sharing economy within most technology communities, a lot of what people are looking for is access. Access to knowledge, access to education, access to mentorship, access to other professional associations, access to learning materials, access to conferences, access to opportunities, etc... As much as people want to share, they also want access to resources. I believe the association can leverage its membership, and bold vision, to create partnerships and ease peoples access to resources.
• To become further engaged with the public and private sectors we need to continue to contribute in a meaningful, and economic way. We need to offer exemplary skills and knowledge that are recognized worldwide further attracting technology projects to Atlantic Canada. 
• As an association we need funding sources. As active contributors to the Atlantic provinces economic future it will be easier to establish partnerships and find sources of funding if we are recognized as adding value and essential resources.

What are your thoughts to my thinking in having a more bold and broad vision for the ACAITA?

Atlantic Canada IT Architects Inaugural Meeting

Let's get this started! My initial call to start an Atlantic Canada Association of IT Architects (ACAITA) has exceeded my expectations. It has become an association with 68 members and the inaugural meeting is happening 6 pm March 9th in Halifax. If you live in the Halifax area and are attracted to participating in a group who describes themselves as;

...people interested in the intersection of business and information technology. And how solution and enterprise architecture can bring stronger, more organized, technology to support and enable business goals and strategy. If your a business person, a technology architect, a web or mobile developer, a senior-level manager, an existing IT professional, a seasoned software developer, or a person with curiosity wanting to discuss the best ways to design and deploy information technology this group is for you.

ACAITA Inaugural Meeting:
Location: The Beer Market - 2nd Floor of the Lower Deck - 1887 Upper Water Street, Halifax
Date: 9th March 2017
Time: 6 pm - 10 pm
Hashtag: #ACAITA

AGENDA:
Kickoff: 6:30ish

ACAITA Business

1. Community Building - having good representation from all four Atlantic Provinces, How do we do this?
2. How can members contribute to fulfill its goals or how this association can help individuals (members) to build their careers?
3. What kind of other online presence ACAITA needs (outside of Linkedin)? This could be link back to our first agenda item.

Discussion Themes

• The Business Value in IT Architecture - we need to attract attention outside of the architecture community and increase understanding of IT Architecture in general
• The Roles of the IT Architect - What is an Architect? And what do they do? Related back to item 2, where is the business value.

I strongly believe we need to move around Atlantic Canada for our face to face meetings, for we have good distribution of our membership. We also need to keep things virtual so using social media will help greatly. Attach the hashtag #ACAITA to all you do.

one hundred and fourty seven

I offered up the idea of an Atlantic Canada Association of IT Architects five days ago and so far the idea has over 140 views and 20 people have expressed interested from different areas within Atlantic Canada and beyond.

Where the interest in ACAITA originates. 

I've taken this as a vote of confidence in the idea for the ACAITA and created a linkedin group to work as the community space where we can all engage, discuss, and grow the IT Architectural capabilities of Atlantic Canada. Join the group by following this embedded ACAITA LinkedIn Group link.

Getting started with the ACAITA

This group is for people interested in the intersection of business and information technology. And how solution and enterprise architecture can bring stronger, more organized, technology to support and enable business goals and strategy. If your a business person, a technology architect, a web or mobile developer, a senior-level manager, an existing IT professional, a seasoned software developer, or a person with curiosity wanting to discuss the best ways to design and deploy information technology this group is for you.

The Atlantic Canada Association of IT Architects (ACAITA) is the leading forum for all professional IT Architects and Technology planners in Atlantic Canada.

Our Vision is to be a forum for excellence that will increase the awareness, effectiveness, and value of IT Architecture for practitioners and organizations.

Our Mission is to be a leading proponent of successful IT Architecture practices within Atlantic Canada.

Our primary goals are to: 
- Help our members build their careers as Information Technology Architects
- Provide a community for IT Architects in Atlantic Canada to share and collaborate
- Increase the maturity and awareness of IT Architecture in Atlantic Canada

Who Should Join?
o   Enterprise/Security/Data Architects
o   CIOs/CTOs/CISOs
o   Computer Engineers/Scientists
o   IT/Network Managers
o   Network Designers/Architects
o   Program and Project Managers
o   Business Unit Managers
o   Solution Architects
o   Specialists/Analysts
o   System Engineers
o   Acquisition/Procurement Managers

The roles of the IT Architect

If you read across the different references, magazines, forums, groups, etc. (online or otherwise) that discuss Information Technology Architecture you will find their are many different IT Architect roles. Off the top of my head I can name 10 different architect roles, they are;

1. Business Architect
2. Information Architect
3. Infrastructure Architect
4. Database Architect
5. Security Architect
6. Software Architect
7. Component Architect
8. Application Architect
9. Solution Architect
10. Enterprise Architect

Surprisingly, these 10 distinct architect roles have little overlap. With the exception of software and application architects they each need a different, yet similar, set of skills and knowledge. I see there being three themes of architecture; development (as in software development), infrastructure (as in building and deploying the infrastructure to support the software), and alignment (as in aligning with the business and information needs, and supporting the business strategy).

I believe the different architect roles fall into these three themes in the following ways;

Development Theme (responsible for designing, building, selecting, and implementing software solutions).

1. Component Architect - designs a specific and specialized software component, needs to ensure it aligns with application architecture.
2. Application Architect (same as Software Architect) - designs (and extends) the specific application to fit the project specifications
3. Solution Architect - understands the extended environment for where and how the application needs to exists. Designs for how application will integrate with greater whole.
4. Enterprise Architect - sets the technical standards and governance for the overall organization. Ensures all new solutions integrate well with organization and makes final call to technical solution environment.

Infrastructure Theme (responsible for designing, selecting, acquiring, configuring, advocating for, and implementing networking, server, security, and storage infrastructure).

1. Database Architect - designs, develops, governs and integrates database technologies. Works closely with development architects.
2. Security Architect - all things security (physical, technical, virtual, and otherwise)
3. Infrastructure Architect - all things infrastructure!

Alignment Theme (work with other architects and business stakeholders to ensure technology is aligned with business strategy).

1. Business Architect - works toward common understanding to bring alignment with business strategy and tactical plans. Seeks continuous improvement for the business, often using technology.
2. Information Architect - looks to bring alignment across information; whether this be branding and usability or how information and knowledge is stored and found within the organization. 
3. Enterprise Architect - The enterprise architect also has much to contribute within the alignment theme. This mostly occurs with governance and to ensure technology aligns with the business.

What I find most interesting is how the enterprise architect needs to have solid relationships with most all other architect roles. And often they will facilitate discussions among all roles to bring together the most effective and broad solution to meet both business and technical needs.

Computer science taught as an art

I've been involved with learning, teaching and creating for all my life. During my formative years (in-utero to shortly after high-school graduation) I was focused on getting what I needed to finish. I was also involved in a lot of art (music, graphic design, crafts, dance, theatre) but my socially encouraged (my parenting) focus was on math and science. Needless to say, I have had my feet firmly planted in both art and science my whole life. I guess most people are this way, with different ratios of art to science. I really feel I continue to straddle both these areas as I pass my 1/2 century mark. What this has given me is a deep appreciation and engagement in both art and science. This is why I am more broad than I am deep. And this is why I have learned art as much as I have learned math and science.

Now I am an enterprise architect, educational technologist, computer scientist, teacher, visual arts performer and all around nice guy (well I hope). I still draw and paint, play music (the best I can) and dance in the open. I encourage my kids to engage in art more than science. Surprisingly, my kids math and science skills are good. I do think there is a connection.

I also think computer science can be taught very well as an art. Particularly, in the early stages of learning computer science. Why? Because, it needs to be done with reckless abandon and with the freedom to make a mess. You need to be able to stop half-way and throw it away. You need to be able to change it into something never planned. You need to be able to break something, and then fix it. You also need restraints through assignments (or learning themes), focused subjects, a palette, skills and abilities, uncertainty and little preparation, it all needs to be inspired and interpretive. I also see taking risks and "feeling stupid" is safer with art than science. Doing a scientific experiment seems more serious than dancing like no-one is watching or painting for yourself. Art seems more reckless than science. It is this recklessness that makes art more accessible to learn than science. I also think there is a lower barrier to entry for art than science, though I don't think it needs to be this way.

How I perceive creating and learning art.
My participation in the arts comes in two themes; the visual make things (graphics, painting, architecture, woodworking, and building) and in folk music and dance. How do I learn new things within these realms; by doing, with a whole lot of reading, research and seeking out those who have done it before. How do I believe it best assist to others learn; by involving them, and pointing them toward understanding how they themselves learn and encouraging their own research practices. Together we do things, I've built and created many things with others and the conversation and collaboration is a beautiful thing. Bringing together music and dance is an amazing collaborative effort. Best done with a willingness to fail, and the patience to persist. One of our best dances is tri-martal-o (it took two years to develop), is hauntingly beautiful, the music is inspired and the piece is way fun to dance. The important aspect of learning art is to dive in, create and participate as soon as you can. And remember, make a mess.

How I perceive creating and learning computer science.
Immediate feedback is the way! Being able to get something working by using the tools and techniques immediately is paramount to learning computer science. Programming something and then seeing it run, render, compute... is preferred for learner engagement. Once this immediate feedback has been experienced, the opportunity to create has been fulfilled, and a good number of computing science tasks have been completed then the deepening and complexity can begin. And this deepening and complexity needs to grow iteratively with continued immediate feedback and fulfillment. It should almost be like playing an instrument or creating art; repetition, creation and fun.

I believe it is also important to understand computing science as a creative and where it fits within the big scheme of things (historically, culturally, epistemogically, and algorithmically). This helps to put computing science into life context. Where it fits with being a human being, and this is where it gets interesting. The ability to take working ideas out of your brain and use them (in other ways and experiments) within a device outside of your head. This is computing science, and it is unique in history. For thousands of years we have taken ideas out of our heads and created things; first, wall paintings, then tools and writing, then machines and engines... but now, we can re-incarnate a working idea in another device that can process the idea, and use it with other peoples ideas, or more of our own ideas. And we can process these ideas as experiments and run a collection of ideas for days with different inputs which influence further ideas.

How do I see teaching computer science as an art? 
Create, make a mess, work with others, make... this is why I see the maker movement so positive. And why the webmaking initiatives currently underway as the right way toward teaching computer science. It creates a low barrier to entry and encourages learning with reckless abandon while on a journey of skills and knowledge development. Webmaking also takes learning computer science into the realm of social learning, which I consider more closely aligned with learning the arts than the sciences.

But how would this work for the more complicated computer science topics? The solution is in how more complicated art projects are created. They are more collaborative efforts, where the more experienced are given the complicated tasks and have to be sure their direct collaborators are also engaged. And there is a whole bunch of healthy collaborative critique going on. Look at how a performance art piece is created, learned and performed. What can be taken from this process and applied to teaching the more complicated aspects of computer science.

In my opinion one of the best books when considering the creation of computer software is written by Russell Shackelford and titled "Computing and Algorithms", I've used this book a number of times when teaching entry level computer science. What I fond strongest in this book is how it connects the creation of computer algorithms (software) with art from the scientific perspective. Or at least that is how I read it...

So in the end when teaching computer science as an art it also comes down to practice, practice, practice... if you want to be a good artist, that includes a lot of practice. If you want to be a good computer scientist, that also takes a lot of practice. The key is to find fun, creative and collaborative ways to stay engaged, and treating the learning of computer science as an art will keep it more engaging. Regardless of age. And as the projects and learning become more complicated, increasingly engage others who are peers and mentors. Find the fun individually and as a group.

Cub Scout Badges as Digital Badges

I'm looking at implementing Digital Badges for Scouting Canada badges. The interesting part is many of the features for distributing and hosting the digital badges related infrastructure and features are available with Mozilla Open Badges and Scoutstracker. Using these existing platforms and approaches is a good idea, so I reached out to Dakemi Communications the maker of scoutstracker. The contact was successful and, to make a long story short, I need to write a few user stories regarding the use of digital badges within scouting.

Note: It is important to recognize that Mozilla open badges provide features where digital badges can be verified as reputable. The issuer and earner of the badge can be verified toward the issuing of the badge and the assessment of the skills and knowledge implied by the badge can be confirmed. In other words, the skills and knowledge identified by the badge have been recognized in the recipient. And digital badges can't just be copied from one person to another.

Actors:

• Scout - this can be a person who has earned badges in any of Cub Scouts (8 - 10), Scouts (11 - 14), and/or Venturer Scouts (14 - 17). These badges collectively show the beginnings of mastery in many areas, and are well assessed for completion. 
• Leader - this is a person (or group of persons) who has evaluated and awarded a badge.
• Observer - this is a person interested in looking at a Scouts badge accomplishments. This could be a potential employer, a college or university, a volunteer organization, a friend or associate, a parent, or anyone interested in looking at a scouts badge accomplishments. 

User Stories:

• As a Scout I want to display my scouting accomplishments (badges) in my social media like facebook, tumblr, linkedin, Etc...
• As a Scout I would like to display all the badges I have earned since beavers, and be able to organize the badges into themes across all my scouting years.
• As a Scout I want to organize my scout badges as clusters to show the themes of my scout accomplishments alongside with my other similar (non-scouting) accomplishments.
• As a Scout I want to review the digital badges of someone I admire or someone further along the scouting path than myself. I want to identify the accomplishments of another, so I can follow a similar learning journey.
• As a Leader I want to see the scouts have recognition for their accomplishments (both online and off).
• As a Leader I want to assign badge completion and also award through information technology and the internet.
• As a Leader I want to support the scout in promoting their accomplishments while not wearing their scout uniform.
• As a Leader I want to display my Scouting accomplishments in Facebook and LinkedIn.
• As an Observer (employer) I want to review a persons accomplishments to assess their character and work ethic.
• As an Observer (parent) I want to encourage my child to have a healthy and strong online persona.
• As an Observer (University recruiter / admissions) I want to get a view into a persons background and accomplishments outside of their academic accomplishments.
• As an Observer (associate / new friend) I want to view a persons background.
• As an Observer (friend) I want to have fun with other friends in sharing our personal accomplishments.

Key organizational items to grow Enterprise Architecture

I am increasingly thinking about what needs to be in place for an organization to be successful with Enterprise Architecture (EA). What I am focused on now could be considered pre-EA items, I believe good architecture can begin (and bring value) at any time within an organizations life-cycle. I also believe EA will be more effective if supported, and initiated, with the following items in place;

• A Project Management Office (PMO) - good project management goes a long, long way to ensuring project success. What is also important for EA in relationship to a PMO is how well the project portfolio (PPM) is managed. And how early in the project discovery the architect is engaged. The earlier the better.

  

  The Project Portfolio Management bicycle.

• A strong voice at the senior management table - for enterprise architecture to have an impact across the organization it needs an advocate and technically knowledgeable voice in the senior management group. This will increase the success (and reduce the costs) for all IT initiatives.
• Processes that encourage (even force) engagement by ALL project stakeholders - early engagement by ALL stakeholders is good! Seek them out! enough said.
• A mindset to reduce duplication wherever is reasonable - look broadly across the organization and identify IT process, software applications, infrastructure, and practices that are duplicated. Work to reduce this duplication. Sometimes... different business domains have different requirements and duplication makes sense, this should be the exception.

I do recognized there is much much more to Enterprise Architecture, but I believe these are a few of the important practices that need to be in place sooner than later when encouraging a solid enterprise architecture practice.

An Enterprise Architecture Elevator Pitch

"The Enterprise Architects business value is in building success through good design. This will vary from place-to-place (project-to-project), because the IT history, context, and organizations maturity will change. In the end, it is about improving an organizations return on IT investments through broad and intelligent information system design and proven architectural practices."

Ask the recipient(s) of the pitch to go for coffee...

BING - door slides open, pitch ends...

So what do I mean by those above three sentences?

1. Business value, building success, good design? - properly designed IT architecture provides a set of technologies (process, features and infrastructure) that eases (and if I may be so bold, guarantees) project success. Project success (particularly when the project is aligned with strategy) adds business value. And the value comes through; being on schedule, staying to budget, shipping reliable systems, enabling business agility and innovation, being repeatable, streamlining process, providing information for decision making.
2. Vary from place-to-place, history, context and maturity will change? WTF? - a good enterprise architect sees beyond the technology and recognizes that every business has a culture, and this culture is influenced, and perpetuated, by the organizations history, the context of the current architectural decision making, and the technical maturity of the organization (in particular, the senior personnel).
3. In the end, return on investment, broad and intelligent design, proven practices? - the enterprise architect needs to prove influence over the end product of working software and systems. If they can't show how they add value in measurable ways, and have this as traceable, people will struggle with seeing the enterprise architects value toward the IT investments. The enterprise architects work needs to been seen as working across the organization, if there are groups left out, the technical debt created by an outlier and having to bring alignment will counter the savings attained through the good architecture. The practices need to be repeatable by other architects, this shows maturity, and maturity reduces chaos.

How does the network see your personal brand?

Branding is important. It provides an external (or public) theme for endeavours; business endeavours, professional endeavours, organizational endeavours. Personal branding has become increasingly important in the networked age where the communications technology (read: Internet) reduces the barriers to promote and communicate brand, even personal brand.

How klout perceives me... https://klout.com/prawsthorne

I have gone through my personal branding exercise a few times in the past, and what I now find most interesting is what the feedback loop in my network sees as my brand... when I traverse the keywords/themes that myself and Google+, LinkedIn, Klout, and other social media have tagged to my respective profiles I am left with the personal branding of; Technology, Architecture, and Education. And my network brands me much stronger in the technology and architecture realms than the educational. I know this branding assessment is somewhat a self-fulfilling prophecy as I have been the one who has joined the groups, followed and friended the people and organizations, blogged about subjects, added keywords, created profiles, contributed to discussions, attended events (online or otherwise), etc, etc... but there are also data analytics going into all this. So by giving a broad sweep over ALL my connections to the network and paying attention to the keywords getting bubbled to the top by the network and the related analytics should give you an idea of how the network sees you.

How my linkedin endorsers perceive me... 

Am I OK with this? Absolutely!

Having a brand of; Technology, Architecture and Education? Does my data analysed network perceive the brand I would like to be perceived with? Absolutely! Most of my professional life, over the last 15 years, has focused upon enterprise and solution architecture. I am a technologist first, with proven successes in architecture. I am also an educator with experience as college and university faculty with a number of technology projects in the edtech realm, where I have increased access to education using technology innovation and solid architectural approaches.

How do you create, alter, and promote your personal brand?

This is where it gets interesting. How do you create, alter, and promote your personal brand? This is what I believe are the steps toward branding yourself;

1. What would you like to be? What is your personal brand? Create a vision for yourself.
2. Be that person. Even if you are not there, yet, be that person as best you can given the real world constraints.
3. Set up a Personal Learning Network (PLN) in the subject areas of your personal brand. Read, research, participate, engage, become.
4. Also use traditional approaches to learning, this will also help with building expertise and grow your network.
5. Write and engage with the social network, be broad with your use of tools. It is amazing what you can learn online with a well designed personal learning approach.
6. Be very public with your learning. Also leverage your existing expertise and blog and engage. Curate wikipedia pages or other knowledge bases in your chosen subject area. 
7. Wherever you participate be sure your personal profiles are up to date within that social media.

What if you are already an expert and have an established personal brand?

1. Keep going. Engage the communities and social media, share your knowledge.
2. Push your life-long learning, add to your personal knowledge. Write about your learning, it is one of the best ways to commit the new knowledge to long-term memory.
3. Continue to curate your shared knowledge across knowledge bases.
4. Be a guest blogger and seek out opportunities to write for popular sites.
5. Participate in online learning forums and MOOCs.
6. Don't forget that publishing is not only written. There are many ways to share; YouTube, Slideshare, Google Docs, Podcasts, etc... be sure to attach the correct keywords.
7. Tweet, Message, Promote... all good.

What if you want to alter your personal brand?

1. Saturate your network with the content (created and/or shared) aligned with your brand change.
2. Be very public with your learning toward the brand change. 
3. Publish your existing and growing expertise.
4. Participate as broadly as possible.
5. Find the related online communities, engage.
6. Curate the subjects within your this new subject domain.
7. Create and add valuable new content.

Major Chords 4 Bass with Tabs

As the family band grows and improves I put together this one-pager for some of the major chords on bass guitar. I helps the boys as they pluck around with the bass, it adds another OER to the space, it helps me to deepen my understanding of the bass. All good.

Click this link for listing of major chords with tabs for bass

Business value and reducing IT duplication

Duplication of features is where I consider one of the easiest areas of IT architecture (enterprise or otherwise) to reduce cost and increase the business value of investments in IT and related technology architecture. In general, I take the view that architecture pays for itself (and then some) when brought into, or given greater influence toward, an organization. This post focuses on architectural duplication, the idea being that an organization has software systems or technical infrastructure that are duplicates of one another. Any piece of information technology (IT) has costs; these costs start at the decision making around acquiring (or building), and continue into implementation, and then exist over the life-cycle of the IT item. Some say the cost of maintaining software is as high as 80% over the life of a piece of software, either way maintaining software (bought or built) cost money and having duplication of systems or features increases these costs unnecessarily. I believe that any architect worth their salt, and working in a medium size organization or larger, can easily pay for their salary simply by reducing duplication and optimizing implementation to reduce licencing costs.

Identifying and reducing
What is the best way to identify duplication? Start with creating an inventory of all software and systems (yes, surprisingly not every organization does this). Make sure this inventory crosses all silos of the organization. Do the follow-up, talk with all stakeholders responsible for software, infrastructure, and related licensing. Create a spreadsheet, diagram, database, or whatever works best for you to visualize all the software, systems, etc... make sure you have a good written description of each. Be sure you can discuss the diagram in a vocabulary that each stakeholder understands. If you can get a sense of cost associated with each, get that information... reach out to the help-desk to get information of which systems require the greatest support, look into the ongoing data entry (duplicate or otherwise) costs, find out how many simultaneous users each system has, gather licensing costs. With all this information you should be able to identify duplication across the silos and within the software features. There will be duplication that can be "easily" removed or licensing schemes that can be adjusted.

Regardless of the cost in doing all this work, it will be less than the savings collected from reduced duplication and over-subscribed licensing.

-- If you want assistance with this or similar IT architecture initiatives feel free to contact me;

Peter, the pragmatic architect.