What is the “systems flexibility curve”?  As an enterprise architect, I am frequently asked to help business leaders decide on which solutions and approaches to use to fulfill a business need.  These decisions are often the inflection point [investment wise] of millions of dollars over many years and in some cases can be of a very high level of criticality to the business.  The “systems flexibility curve” is a visual representation  of the trade-offs uncovered when determining the best way to fulfill a business need with a solution.   The chart represents several competing interests.  When we look at the various factors involved with using technology to fill a business need there are competing factors.  This graph was created out of a need to help mostly non-technical people [business leaders] understand some of the factors going into a build vs. buy and or new solution discussion.   I will try and define them for the reader here:

• Automation: – This is describing the level of process automation and configuration that comes out-of-the-box.  This means that your business processes are integrated and highly automated.  Some examples include typical vertical solutions such as mortgage origination, work-order fulfillment and  accounting software suites.  In these scenarios, the business processesare a commodity and common.  In a scenario with a need for high automation, you are typically purchasing the business process and the software.
• Flexibility: – this factor describes the level of flexibility beyond typical configuration.  High flexibility is sometimes warranted where there specific business needs that require a high degree of customization.  High flexibility is almost always associated with custom software development, where solutions are created from the ground up.  In product development there is almost always a high need when compared to traditional industry vertical scenarios.
• Implementation Speed: – this factor is trying to describe the speed at which a solution can be delivered.  From concept or need identification to roll-out in production.  This includes configuration and testing or development, testing and deployment.
• Manual Intervention: – in this case we are describing the need for ongoing intervention or maintenance on the solution itself over time.  In a custom developed solution, the solution will almost always require bug-fixes, process change work in the solution as the business processes evolve over time.  In buy scenarios, these activities take place, but the originating vendor bears the cost, not the purchasing organization.

With those descriptions established, lets talk about what the chart means in it’s totality and how it can help you in your enterprise architecture activities.
At the far left of the graph we see a system that is custom-built to the exact specification of a business process where the customer [business partner or client] has complete flexibility.  A solution in this space requires significant long-term investment in maintaining the custom built solution and thus the high labor costs and associated risks.  The final attribute of a solution to the far left is the slow speed of delivering the solution.
A solution at the far right of the graph is one that was purchased and deployed out-of-the-box with little configuration.  Thus we see the automation is high with regard to the business process.  The high systems cost is representing the purchase of the software or solution and the high one-time, upfront costs.  The speed of implementation is very high.
The truth is that most solutions that get deployed into production are typically somewhere or on some scale in the middle,  it is pretty unlikely that a solution would be on one of the extreme ends of the spectrum.
In conclusion, this graph or visual representation of the systems flexibility spectrum has been very helpful to me over the years and I encourage others to use it as well.  There are assumptions made with the graph and these rules are mostly true.  There are some outliers that make these assumptions untrue.  There are ways to get the worst of both ends of the spectrum.  The most common is the typical ERP trap where an organization purchases a software package and customizes it to the point where it is no longer maintainable by the vendor.  This is literally the worst of both worlds where you pay for the customization and the high maintenance costs.  This is broadly considered to be an anti-pattern in the industry.  Enjoy!

by Erik Peterson

IoT is all the buzz and for good reason as man and machine continue get along better. Our world is changing.

Ardec has been and continues to be a player in IoT since 2001 with  patented tech that I and several of my brilliant talent were co-inventors on. Yeah, 15 years ago. Anyway, lets simplify what you need for IoT and I'll use some examples from that patent. 

Some background...the business idea was that the Ardec client wanted to sell age-verified items from a vending machine. Simple right. Well, we rocked the vendor conference in Chicago when we unveiled the system. It landed us in national news that syndicated across the US. I hope your IoT rocks too!

So how did Ardec do it?

IoT has three basic components: 1) smart electronics, 2) device packaging, 3) get connected.

1) Smart Electronics
Below is the diagram of the smart electronics complete with special sensors, logic, communications, etc.
​

2) Device Packaging
Smart electronics need form, a way to be installed, provisioned, updated, etc. Most of all its usually the packaging that provides the connectivity from the electronics to the physical world. Below is the packaging ("device") in our system.

3) Get Connected
In Ardec's case we could have built the device without any connectivity. But I had this craving to just remote control the thing rather than send a technician on site every time the thing needed to be kicked.

We constructed multiple ways the system could connect over wired and wireless protocols to a software communications system with web API's. The comm server then connected to a business server where most of the logic was held. A web UI then gave the business a way to control or delegate control of 10s of thousands of devices. 

Ha ha, you know as I look at these drawings, I am sooooo glad for better drawing tools like LucidChart! 

Wrap up
​Your device needs smart electronics, packaging, and connectivity. Stop thinking about it and build it. Change the world! Ardec has a way of simplifying otherwise complicated systems. If you're into IoT let's chat about what you're doing. It's really is exciting to see, not the beginning of IoT, but its explosion.


​

by Alan Rencher

I am often asked which Enterprise Architecture framework I like and which one I recommend.  This is usually a very quick discussion where I try and explain that there are great reasons to use a few different ones but I have my own biases and opinions.  I try and encourage the serious answer seeker to decide for him or herself and will recite a platitude about there being a few good ones and you should study them and decide for yourself.   In the end the person typically just says something like: “Just tell me which one I should use.”  This kind of bothers me, but if I am nailed down I usually answer: TOGAF.  I want to put some color in the conversation and in this entry I will try and describe the top five frameworks, my take on their strengths and weaknesses and why I like the ones I like.

A very brief discussion on the practice of Enterprise Architecture may be in order.  In the late 1980’s a guy working for IBM named John Zachman coined the term “Enterprise Architecture”, he did this in a seminal paper entitled “A framework for information system architecture“.  In this paper he outlined potential steps and practices for making good architecture decisions with regard to many different and varying factors.  Since then many other smart people have implemented similar frameworks and processes.

In alphabetical order, here are the top 5 that I have experience with and think are sound.  I will attempt to provide some strengths and weaknesses for each as well as some brief experiences I have had with them.

DODAF – This is the Department of Defense’s  [DOD] framework created initially in the 1990’s as a “more secure” version of some loose standards that different branches of the armed forces had at that time.   This framework is rather large and complex.  It is suited for extremely large systems that have very challenging integration needs and extreme performance and security needs.   This framework is too big for one person, or even a team to become expert on.  I was required to use nomenclature and diagrams using it’s standards when I was helping run a defense contracting technology company that was building and integrating supply chain systems for the USAF and later the DOD as a whole.  It was actually very different than Zachman and was very challenging to understand.  One of the strengths of the DODAF framework was it’s focus on what it calls “Operation Views” and modeling and representing them from different perspectives.  I would not recommend this framework to anyone or any organization unless you are working for a DOD related entity or a defense contractor.

GARTNER – Gartner offers an Enterprise Architecture process and practice with some elements of a framework.  For our discussion today we will refer to their offering loosely as a practice.  This practice focuses on what Gartner refers to as “business outcomes”.   The Gartner practice is heavily weighted toward defining a “future state”  and everything working toward that outcome.  In principle, I like this but their practice seems rather lean in giving you tools and emphasis on the “how” you get from your present state to your future state.   I had a lively discussion with Betsy Burton and Brian Burke at a Gartner symposium last year on this topic.  The Gartner practice is very business friendly and is seeing some real momentum in the industry right now but is still not widely adopted.  I am not entirely sure why but suspect that in the coming 18 months this practice will start to really get wider adoption.  We’ll see.  I really have not used their practice exclusively so my experience with it is all speculative and academic.

TEAF – This was the “Treasury Enterprise Architecture Framework”.  This is a dead framework that I used when building systems for a major financial services company earlier in my career.  It was a derivative of the Zachman framework that specialized in tighter security controls and was initially sponsored by the US Department of Treasury.  I used this back when it was a brand new standard and in all candor was terrified of it.  It was heavy and scary.   It had a rigid list of vocabulary that differed slightly from Zachman and really focused on a series of matrix views that enabled “intrinsic perspective”.  Apparently this framework has been consumed by something even scarier, the dreaded “Federal enterprise architecture” or FEA framework.  All jokes aside, I am not super familiar with FEA other than the hallway conversations at EA conferences.  Some former colleagues in the federal contracting industry have described it as exceptionally heavy and almost as overwhelming as DODAF.  Time will tell.  Perhaps this framework is responsible for the Obamacare health exchange disaster?  Just kidding….

TOGAF – This is “The Open Group Architecture Framework“.  This framework is created and maintained by the OpenGroup.  This open standards based group is comprised primarily of industry thought leaders and seasoned EA professionals.  This group is influenced at least somewhat by their corporate sponsors.  These sponsors are very numerous but the big mega-vendors comprise the “platinum” sponsors.  My own opinion is that these sponsorships are very healthy and represent an extremely wide diversity of corporate interests.   TOGAF splits all architecture activities into four domains or categories: Business Architecture, Data Architecture, Solution / Application Architectureand Technical Architecture.  These categories are worked on in various phases that happen inside of what TOGAF describes as an Architecture Development Method.   This is a series of steps and or activities which help the architect arrive at a usable architecture to help the business reach it’s goals.  Some purists and others dislike TOGAF because you have to pay to become a member of the OpenGroup and you need to buy the materials and  pay for the certification tests.  I have purchased the materials and I have taken the certification tests.  I am not a TOGAF purist but I like the tools in the TOGAF toolbox and I use them when they make sense.  I have delivered value with the TOGAF toolbox.   I personally get a little overwhelmed even thinking about strictly following the TOGAF ADM to the letter.  It is my own personal preference.  I do have a mild criticism of TOGAF myself in that it does not provide a super-heavy security emphasis.  This can be overcome by discipline and your own focus, or just including security requirements as part of your initial business architecture.

Zachman – This is the Stradivarius of Enterprise Architecture frameworks.  I have used it extensively early in my career and cut my architecture teeth with it designing home automation and engineering process software.  It uses a very extensive matrix of steps of design.  I liked it because it was easy for me to understand.  It used simple descriptions like:  who, what when, why, where and how to describe different layers of maturity in your overall design.    John Zachman was a visionary man.  He was a game-changer.   His framework is still somewhat popular and many organizations still use it.  Nearly all EA frameworks trace their origins to Zachman.  The challenge with Zachman is that it has not adapted to the levels of complexity in the industry even though it has gone through several revisions.  That is my opinion.  I have had long discussions with many who I respect who would disagree.   In my mind the simplicity of the more recent additions have made the Zachman framework kind of like a nice classic car that is fun to get out and drive once in awhile for fun but not something you want to drive to work on the freeway every day.

All of these frameworks add value or have added value.  There a few others that I have not mentioned that some practitioners will undoubtedly call for the leaders spot.  At the end of the day, in my present practice, I draw on all of my varied technology and leadership experiences that have their roots in all of the frameworks I have been exposed to.  I draw most heavily from TOGAF and at this point in my career use TOGAF by far the most.   I guess I am a TOGAF guy for the most part.  I would love to hear which frameworks have added the most value for others.  In closing, I feel that there is actually a pretty big hole in the EA space.  I believe that there is ample opportunity to provide a much more simple framework that would probably borrow heavily from a few of these more well-known frameworks to create a simple, programmatized framework.  I wish I had a lot of free-time to go do it myself.  Who knows…….

by Alan Rencher

​I remember as a young man thinking about all of the amazing possibilities that would be around when I was an adult.  I remember the prognostications about flying cars, self-driving cars and of course the "Mr. Fusion" portable nuclear reactor from Back to the Future.  At that time in my life I really believed that anything was possible.  Looking back on the 1980s and some of the predictions and futuristic thinking taking place at that time, some of our expectations for the future were a little strange.  Some were right where they should have been.  Remember the kids cartoon Inspector Gadget?  For the younger readers, let me give you a brief synopsis.  He was a hapless crimefighter who had robotic arms, gadgets and other things that he could do.  He would say things like "Go, Go Gadget hair dryer" and a robotic arm wit ha hair dryer would come out of his hat  and dry off his hands.   His car would "transform" from a police van to a submarine and things like that.  His niece "Penny" and her dog "Brain" were typically the figures behind the scenes making things happen and solving the actual crime or mystery.  Inspector Gadget 's nemesis was a shadowy figured called "Dr. Claw" the leader of a sinister criminal syndicate called "MAD".  In this cartoon, "Penny" and her dog had all kinds of really cool gadgets they would use to fight crime.  Penny and her dog had "video watches" and headsets that allowed them to talk without any wires and of course, who could forget Penny's "computer book".  This book could solve difficult problems, compute complex physics questions and could control all manner of other electronic devices and other things.  These devices seemed almost whimsical and unrealistic to many at the time of the cartoon in the early 1980s.  

​All of these devices exist today and really are not that surprising to anyone, in fact, many wonder why they took us so long to bring to market.  The level of innovation is accelerating.  Companies are bringing technology to market faster and connectivity and processing power is starting to appear in everyday items that are becoming more and more mundane.  The recent IoT or "internet of things" buzzwords are becoming more and more part of our everyday life.  Sensors and data creation points are creeping into more and more aspects of our personal and professional lives.   At this point, nearly anything is possible with technology, the science fiction ideas of yesteryear are science and technology reality today.  Are you and your business ready?   Do you understand and comprehend how you and your company need to take advantage of these digital assets and technologies to further market to and engage your customers and users?  Do you  have a plan to do this?  

by Erik Peterson

I'll kick off our blog with some discussion about an Ardec favorite moto I coined some ten years ago, "Wise investments, well managed". This has been a strong agenda of mine for my clients. Too many decision makers, and some who started with deep pockets, seem to just burn through money on this and that technology. Well yes, like me driving a green at 300 yards can and has happened, throwing money at technology in a "swing for the fences and just maybe" mentality just doesn't cut it. 

Additionally, how many of us would spend the money to put in a beautiful lawn and then let it go un-watered, un-fertilized, un-cut? Was the grass bad or the care? That unfortunately happens with technology spend too. I've seen the fallout from management spending big bucks on some great tech, then walking away like they think it will magically take care of itself. How about this scenario, ever seen some forget that no matter how awesome the tech, it takes talent to operate...and usually other investment too. Let's stop buying Ferrari's without steering wheels, and parking them on the lawn and using them for flower pots. Ha ha, too fun poking at some of the poor patterns I've seen!

The point is that there are sound principles for technology investment and management. Let's learn them. Let's apply them. I hope this blog and Ardec's services can improve the economic waste from bad, poorly managed investments. 

Buy well, drive well.