A plethora of end points

There is a growing number of data collection devices available to the digitization of everything (including oceans). The variety of devices and sensors includes everything from temperature through chemicals to acceleration. Combine the number of different sensors with the ability to transfer data over great distances and the ability to monitor even the most remote places for obscure data points is increasingly easy and affordable. The following list provides an overview of the types of devices and sensors available.

Internet of Things (IoT) Sensor Classification from Black Box Paradox.

• Position / Presence / Proximity

  

  Presence Sensor

1. Proximity Sensor - A proximity sensor is a sensor able to detect the presence of nearby objects without any physical contact.
2. Position Sensor - A position sensor is any device that permits position measurement.
3. Presence (or Occupancy) Sensor - An occupancy sensor is a motion detecting devices used to detect the presence of a person or object.

• Motion / Velocity / Displacement

  

  Displacement Sensor

1. Motion Sensor - A motion detector is a device that detects moving objects. Such a device is often integrated as a component of a system that automatically performs a task or alerts a user of motion in an area.
2. Velocity Sensor - A velocity receiver (velocity sensor) is a sensor that responds to velocity rather than absolute position.
3. Displacement Sensor - A displacement sensor (displacement gauge) is used to measure travel range between where an object is and a reference position. Displacement sensors can be used for dimension measurement to determine an object's height, thickness, and width in addition to travel range.

• Temperature

  

  Temperature Sensor

The temperature sensor detects the current temperature or changes in temperature.  There is a large number of temperature sensors available and a comprehensive list is available on Wikipedia.

• Humidity / Moisture

  

  Humidity Sensor

1. Humidity Sensor - A humidity sensor (or hygrometer) senses, measures and reports the relative humidity in the air. It therefore measures both moisture and air temperature. 
2. Moisture sensor - A moisture sensor is an instrument used for measuring the water vapor in the atmosphere. Sometime considered same device as humidity sensor.

• Acoustic / Sound / Vibration

  

  Acoustic Sensor

1. Acoustic Sensor - Surface acoustic wave sensors are a class of microelectromechanical systems (MEMS) which rely on the modulation of surface acoustic waves to sense a physical phenomenon.
2. Sound sensor - Sound Sensor can detect the sound intensity of the environment. The Sound Detector is a small board that combines a microphone and some processing circuitry. It provides not only an audio output, but also a binary indication of the presence of sound, and an analog representation of it's amplitude.
3. Vibration sensor - a vibration sensor can detect vibrations. A transducer, such as that incorporating a laser or a piezoelectric crystal, which converts vibrations into an electrical equivalent such as a voltage. Also called vibration transducer, or vibration pickup.

• Chemical / Gas

  

  Gas Sensor

1. Chemical Sensor - A chemical sensor is a self-contained analytical device that can provide information about the chemical composition of its environment, that is, a liquid or a gas phase. 
2. Gas sensor - A gas detector is a device that detects the presence of gases in an area, often as part of a safety system. This type of equipment is used to detect a gas leak or other emissions and can interface with a control system so a process can be automatically shut down.

• Flow
  

Flow Sensors monitor liquid flow rates and accumulated flow volume. Flow measurement is the quantification of bulk fluid movement and can be measured in a variety of ways.

• Force / Load / Torque / Strain / Pressure

1. Force Sensor - A Force Sensor is defined as a transducer that converts an input mechanical force into an electrical output signal. Force Sensors are also commonly known as Force Transducers.
   
2. Load Sensor - A Load Sensor is defined as a transducer that converts an input mechanical force into an electrical output signal. Load Sensors are also commonly known as Load Transducers or Load Cells.
3. Torque Sensor - A torque sensor, torque transducer or torque meter is a device for measuring and recording the torque on a rotating system, such as an engine, crankshaft, gearbox, transmission, rotor, a bicycle crank or cap torque tester. Static torque is relatively easy to measure.
4. Strain Sensor - A Strain gage (sometimes referred to as a Strain Gauge) is a sensor whose resistance varies with applied force; It converts force, pressure, tension, weight, etc., into a change in electrical resistance which can then be measured.
5. Pressure - A pressure sensor is a device for pressure measurement of gases or liquids. Pressure is an expression of the force required to stop a fluid from expanding, and is usually stated in terms of force per unit area. A pressure sensor usually acts as a transducer; it generates a signal as a function of the pressure imposed.

• Leaks / Levels
  

1. Leak Sensor - leak detection is used to determine if and in some cases where a leak has occurred in systems which contain liquids and gases.
2. Level Sensor - Level sensors detect the level of liquids and other fluids and fluidized solids, including slurries, granular materials, and powders that exhibit an upper free surface.

• Electric / Magnetic
  

1. Electric Sensor - A current sensor is a device that detects electric current in a wire, and generates a signal proportional to that current. The generated signal could be analog voltage or current or even a digital output. The generated signal can be then used to display the measured current in an ammeter, or can be stored for further analysis in a data acquisition system, or can be used for the purpose of control.
2. Magnetic Sensor - A MEMS magnetic field sensor is a small-scale microelectromechanical systems (MEMS) device for detecting and measuring magnetic fields (Magnetometer).

• Acceleration / Tilt
  

1. Acceleration Sensor - An accelerometer is a device that measures proper acceleration. Proper acceleration, being the acceleration (or rate of change of velocity) of a body in its own instantaneous rest frame, is not the same as coordinate acceleration, being the acceleration in a fixed coordinate system.
2. Tilt Sensor - A clinometer or inclinometer is an instrument for measuring angles of slope (or tilt), elevation or depression of an object with respect to gravity. It is also known as a tilt indicator, tilt sensor, tilt meter, slope alert, slope gauge, gradient meter, gradiometer, level gauge, level meter, declinometer, and pitch & roll indicator.

• Machine Vision / Optical / Ambient Light
  

1. Machine Vision Sensor - As a simple concept, machine vision is the use of devices for optical non-contact sensing to automatically receive and interpret an image of a real scene in order to obtain information and/or control machines or processes. Machine vision (MV) is the technology and methods used to provide imaging-based automatic inspection and analysis for such applications as automatic inspection, process control, and robot guidance, usually in industry. Machine vision is a term encompassing a large number of technologies, software and hardware products, integrated systems, actions, methods and expertise. Machine vision as a systems engineering discipline can be considered distinct from computer vision, a form of computer science.
2. Optical Sensor - Electro-optical sensors are electronic detectors that convert light, or a change in light, into an electronic signal.
3. Ambient Light Sensor - A device that detects the amount of light in the vicinity. An ambient light sensor may be built into a smartphone or tablet to adjust the screen brightness based on the available light.

Security matters!
It is also very important to note that as sensors become increasingly available and controlled over the network, security should be of huge concern. Industrial controllers are becoming increasingly targeted for security vulnerabilities and if an oceans sensor is available from a remote location over a network it is potentially open to attack. Being aware of the data available from the sensor and any control features the sensor (activator, controller) may have.

The other end
When considering the digitization of oceans reference architecture and what is considered an end-point we need to also look to the other end. And by the other end, I mean the data storage end. In this post we have discussed all the end points that emit the data, and at some point the data will need to be "at rest" stored in some storage device. The topic of data storage will be discussed in a later post.

Some examples of end-points

• Nomad - The AXYS NOMAD is a unique aluminum environmental monitoring buoy designed for deployments in extreme conditions. The NOMAD (Navy Oceanographic Meteorological Automatic Device) is a modified version of the 6m hull originally designed in the 1940’s for the U.S. Navy’s offshore data collection program. It has been operating in Canada’s Weather Buoy network for over 25 years and commonly experiences winter storms and hurricanes with wave heights approaching 20m.

• Coast Guard Canada - it is very hard to imagine this autonomous vessel will not be loaded with sensors to collect data. Portsmouth, UK, based ASV Global has converted a 26ft hydrographic survey launch to enable it to operate autonomously using the ASView control system, while maintaining its ability to operate in a conventional manned mode. The launch, which is part of the Canadian Coast Guard’s fleet dedicated to the survey operations of the Canadian Hydrographic Service, will be used as a test platform for unmanned survey work.

• Personal Weather Stations - A personal weather station is a set of weather measuring instruments operated by a private individual, club, association, or even business (where obtaining and distributing weather data is not a part of the entity's business operation). Personal weather stations have become more advanced and can include many different sensors to measure weather conditions. These sensors can vary between models but most measure wind speed, wind direction, outdoor and indoor temperatures, outdoor and indoor humidity, barometric pressure, rainfall, and finally UV or solar radiation.

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; "communications" with focus on the data communications available to 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

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