Flipping the Educational Value Chain

Blog post
edited by
Wiki Admin

Business, governments, and even many non-profits have benefited from the windfall of a flattening world – less war, trend towards better resource distribution, new business models, digital economy proliferation, sharing workforce. Education has not

At Xentity, to us exploring NextGen Transformation using architecture, analysis, design is not about IT. IT is a core component, but we are looking at how the Next Generation will progress and transform. And with generation lines becoming more of a blur, this isn’t a 30 year delay, or even a 15 year delay. In some cases, we are talking 5 to 10 years for transformation of a generation. Given such, when we examine workforce capital, we are truly interested in the changing models not just in the employee – which by the way, is a relic of the industrial age – but also how those employed in your organization (employee, contractor, consultant, vendor, service provider), are changing themselves.

One way of examining this is looking at the actual next generation. The kids. This is very important. For instance, the current incoming generation, aside from now being larger than the Baby Boomer generation, has benefited from the previous 30 years of relative stability, and Millenials engage in collaborative environments, as a result of growing up in a connected world NATURALLY.  

They weren’t taught this though, what they were taught for the most part, with some Montessori, STEM Academy, and other cloud school minor exceptions, in a school model that was intended for the children to go into a pre-industrial revolution business workforce that had bells to change shifts, required discipline of a “robot” in the factory for efficiency and safety, and required still minds to take orders and execute.

When examining your organization, you may have unwritten rules, or codes that have been passed down out of habit, institutionalization, or what we know. Those unspoken rules of engagement or life definitely help manage the chaos and focus on the mission, but the question that at times needs to be asked is “Is this the right mission? If not, are these the right rules?” and thereafter of course, do you or does your organization have the political and actual capital to make the transformation.

The following, in two parts, Jim Barrett examines this phenomena of:

Mr. Barrett is not only is Xentity’s Architecture lead, but has actively served and presently engages in multiple early childhood education development advisory and exploratory boards.

 

 

So what is the point of this metaphoric drivel

Blog post
added by
Wiki Admin

So what is the point of this metaphoric drivel about cowpaths, space shuttles, and chariots?

Yes, fair enough. Aside from being a fun story, there should be a point.

I think there are 3, not unlike the Goldilocks story.

Change Agents can’t come in too hot to put in new technology and abandoned the old as there are consequences

Change Agents can’t come in too cold and put in new technologies just putting it in the footprint and same design footprint of the old.

Change Agents need to find the transition balance between the old and new that allows the new ecosystems to be adopted and the old ecosystem to adapt.

To get this balance, there are three factors standing in the way of introducing a disruption such as this:

  • Scaling – Scaling Research Readiness for solution expansion, adoption, and architecture qualities
  • Legacy – Legacy investment stakeholders agendas
  • Transition – Patterns for new investment that benefits the new solution and addresses legacy investment stakeholders

Read the next blog post for considering the disruption factors on an example topic – advancing our global network keeping up with the Computers to make the internet truly 21st century.

More to come.

What cow paths, space shuttles, and chariots have in common

Blog post
edited by
Wiki Admin

A colleague recently sent me a chain email (they do still exist) about the old adage on how new technology is driven by thousand year old standards. I had seen it before. I remember then I liked it. But, my new habit on chain emails or viral urban legends was to poke around. Being childlike, I hope for fun new ways too see things, but being a problem-solver as well, I am skeptical of these amazing discovery of trivial connections. Regardless, its still a fun story where one can mine some good nuggets.

The anecdote essentially notes how historical inventions are connected and a moral. Reading it backwards, it connotes how the width of the space shuttle rocket boosters are due to width of railroad tunnel. And how railroad tracks width are due to the carriage wheel width. And how that width is tied to chariot width because of the width of two horses. Point being, the boosters width is derived due to width of two horses rear-ends.

Like I said, it is fun, but the tangents are more loosely coupled and coincidental than the “seven degrees of Kevin Bacon” concept. Snopes nicely walks us through how while this is true, but only through generalities – not unlike how someone could say the clothes we wear now is because of a medieval tailor sized it that way. Snopes can be a party pooper some time, but they did also note a few things about people and change (insert my agenda HERE). This is why I do like stories like this as I can tie my own tangential take-aways from it.

Snopes points out humans presets on change:

Although we humans can be remarkably inventive, we are also often resistant to change and can be persistently stubborn (or perhaps practical) in trying to apply old solutions to new conditions. When confronted with a new idea such as a “rail,” why go to the expense and effort of designing a new vehicle for it rather than simply adapting ones already in abundant use on roadways? If someone comes along with an invention known as an “iron horse,” wouldn’t it make sense to put the same type of conveyance pulled by “regular” horses behind it?

It goes on for several more examples noting how new innovations leverage the blueprints of previous generation inventions, regardless of their direct influence. The tone felt a bit down when noting this, but I felt this continuity is not wholly a bad thing.

As a physical society that build infrastructure to share, this compatibility is needed to limit the impact of disruption while progressing towards addressing societal challenges of Maslo’s Hierarchy of Needs globally.

For example, lets say there is a future decision to stop using dams for hydroelectric power and go into a series of nano-electric generators that works off river flow that would impede water less and generators more power. This is great as we have a lower cost, simpler, more efficient solution that also does not disrupt the ecosystem such as riparian development, fiash spawning, etc. like dams have for decades.

How do we transition to the new nano solution. The railroad story says we would use the previous footprint of the dam, and once ready, slowly migrate to the new solution to allow the water flow to slowly come back in place. This would allow the wetlands and riparian ecosystem to grow back at natures pace, and allow for fish and river life to adapt generationally.

Yet, the new solution does not require the same footprint. We could build it anywhere along the river. It could even be setup in a series of micro generators, and once the level of energy put into the grid matches the dams, in theory, the dam could just be exploded, and we could progress on without anyone in the future anthropocene historic footprint to be aware that a dam was ever there.

But, removing the previous infrastructure in a responsible way will be key. Blowing up a dam means the water release would cause major sediment displacement, kill the dam-resulted adapted riparians and wetland ecosystems, and generations of fish and river life would actually die as a result. The dismantling process, though not required for the new direct energy human need, is very critical to consider the indirect impact of the evolved ecosystem. 

If still interested, check out the follow-up blog post So what is the point of this metaphoric drivel

To employ or not to employ, that is the architect staffing question

Blog post
edited by
Wiki Admin

Architecture has been a very interesting field to provide as a service. With the various changes in information products, data science, information technologies all building upon each other, its hard not to remain continuously engaged, amazed and curious.

There is the obvious reward of seeing your designs go live with the tangible solution. Web sites, data products, data centers, technology ordering, MIS, software, kiosks, sensors are things you can point at and say “we designed that”. Its a nice feeling. Maybe not as cool and tangible as a building, transportation network, trains, city centers, etc., but nonetheless, there is something exciting, sometimes intimidating about knowing your designs are being used for something real and for the greater good.

Its more of an internal, or dare we say even intrinsic reward, as from a management point of view, typically architecture buys back risk, achieves the expectations, and when all is well, it is a standing outcome that the typical the bulk of the recognition for success goes to the talented IT implementation team. That credit is seldomly connected to the value of the foresight and concepts that were the foundations of enablement of the project or program two or three years ago i.e. the right business model, the capital plan execution, the innovative operating concept, the team vetting and estimation selection. 

Yet, architects do get credit, when there is a “glitch” in the solution. It is not uncommon for that same team to assure the first thought after some cycles is faulty design flaws and the architect is back in the “credit” limelight and until solved or understood, is put right “under the bus”. For example, an airline client called years after the contract was over on several occasions. Once asking if we had broken or illegally used or infringed on patents (which was summarily dismissed); Another time during Y2K, when after 36 hours straight diagnosing the data center tested back-up VPN wire had simply “fallen out”; and finally, when one day prices on the web site sold international tickets for free plus fees, when it turned out it was the mainframe and happend many times, but historically travel agents intercepted the error on behalf of the mainframe.

But, nonetheless, in your portfolio of accomplishments, you can be very proud that you envisioned that concept, design, or solution. Point being, an architect naturally wants to see their design go live, and move onto the next design. Its not like an operations position where they become a master of efficiency in their trade. Or Development where they become an expert in a set of core technologies. Or a requirements or project manager who enjoys the battle of herding cats. An architect enjoys the conquest. They want to either keeping doing similar architectures or grow to the next.

The What is next? driver for architects

That being said, when a technical leader or hiring manager envision what concept is needed for instituting architecture services at their company, they’ll also need to consider, “what will the architect be doing after the next two projects?” as by this introduction, the drivers are very clear for architects in a career “what is next?”. 

  • Will they be churning out more architectures in same patterns, or growing the company, and thus their architecture skills will need to grow with it?
  • What will the role description look like after the first two projects – more technical prowess or more leadership and management growth?
  • What level of architecture services/work is needed against the size, maturity, and complexity of the organization? 
  • After the first two projects, what are the key results needed to measure a skillset that is both needed to have proven history and portfolio of work as well as handle future concepts against the description? 
  • How do you interview and commit for a role – do you assess portfolio for leadership potential or resume qualifications and in-basket technical exercises for the technical depth or both?
  • How do you measure creativity against portfolio trusting it is comparable while not asking too much hypotheticals as architects are built to design for the “what if” and they will beat you every time.
  • Do you know after the first two projects that you will have the challenge the architect will be seeking or that they can handle? 
  • Will it slow down and become a more technical hands-on position or will it speed up and the responsibility will grow, and can they grow with it. 
  • Meaning, what will the level of work look like – not just variable (fast/slow) or stable, but will the role description change or be static or limiting? 
  • Will you need them to take on any task that comes their way or be a strong expert in a specific architecture stack, but those tasks may have gaps in time?

This all said, these are the challenges or hiring a full-time architect. They will be driven by “what is next?” which if you do not know, then your likelihood for expected retention diminish before you start.

Retention and Sizing

Here are a few additional notes on architecture staffing we have encountered and followed by solutions on various staffing models for architects:

Its a buyers market for good architects. Good architects have grown their people leadership, change analysis, results-driven, and team-building skills. Good architects adapt to the subject matter and technical skills become, so that they can handle the rapid change in technology stacks, patterns – those aspects become like “the Matrix”, and they can see through the next technical vendor and industry wave of architecture stacks and grow their value through increasing ROI on services, outlining more valuable or efficient concepts of operation, and easily and collaboratively designing blueprints or transition roadmaps into the PMO change management plans. These positions will pay more, tend to have a lifespan of at most 3 years, and they will get bored. Now if you are hiring for a specific technology architect, then advertise for that and lead with that, in hopes that the stack has a reasonably lifespan and expect limited growth and know their role will be consistent repeat-ability on that stack and grow as only that stack grows and exists. 

Average architects will plateau. If you hired a technical or IT architect, it is more of an analyst or tech team lead architect. They will do this and do it well. If your company though is growing, and changing, and employing new technical stacks, new services and products and new or growing business models, your architect will not grow with it if they were hired as a technical specialist. The role changes from requiring just systems analysis or root cause analysis to business change, policy, or political analysis. The role will now required as the service or product grows in relevance and importance to the organization, a solutions, enterprise or chief architect who is needed that can speak business plan, total cost of ownership, product management roadmap, and present both up to C-level and lead technical teams. The IT or solution architect may struggle with hanging onto to old patterns they know, sticking with the custom portfolio, or worse yet, not keeping up with business management just-in-time training.The hardest part is as they are learning non-intuitive soft skills that go against the more IT introverted hard skill professional profile, they also need to keep up with keep up with the technical architecture changes induced by Moore’s Law and Metcalfe’s law. Typically, this becomes too much learning, and an external or new hire is required. In shorter terms, you wouldnt hire a cook and ask them to farm just because both work with food. This is why Technical architects overengineer as they move up – they do what they know as they move up. Vice Versa as well.

Position is needed for the next two projects, then what? Lets say the architect is brought on for specific architecture skillsets – maybe that is MVC stack flavor of the past few years or maybe that is enterprise architecture analysis – and lets say that architect is hired and is a perfect fit and model architect. As the first two projects wind-down, the problem is time has passed, Moore’s Law has changed, the portfolio requirements have adjusted, but the skillsets chosen may now becoming legacy. It happens that fast. Then, the architects adrenaline wears off from seeing the conquest of going live. They begin to realized the next architecture project is likely not to be a fit. They will tend to either know the end is near or hijack and get “proactive” as business is perceived to delay. As business looks at their next architecture need, data architecture, or process re-engineering, governance or in a new subject matter expertise, they consider if that technical specialist architect can morph.

The answer is technical or application architects do not tend to morph or grow with the organization. Then business considers a new architect, while retaining the old one. Now you have architect bloat, dual roles, and ROI on architecture is at risk of eroding. This is architectures achilles heel, which all comes back to the staffing model. Point being, hiring for the first two projects will yield an average architect, they likely will hit value stagnation, and either reduce into Senior Engineer role, which may be of value, but is definitely a compensation plateau, or they will realize their diminished value and either underperform or encourage them to move on which is just not a good way to acquire talent. Hiring a rock star externally out of the gate will work, but keep in mind they will expect compensation above the organization curve, above inflation, and they will keep up with the salary norms, even if they are comfortable with well-balanced life. They know they can move around to the next conquest.

The position is needed long-term as CIO trusted advisory, but near term, need hands-on technical architecture. Let’s say you instead start out with finding a seasoned trusted advisor, well experience in corporate culture, subject and domain matters, and familiar with patterns in enterprise, process, data, performance, service, technology, and security architectures as well as works well with the various change management domains. They are the perfect fit – except, starting out, you have a project that needs more than a guiding touch, but needs to get their hands dirty in new MongoDB and NoSQL map reduce code analysis. The seasoned veteran has not kept up with actually coding as they have been on higher order tasks, as they should. This gap between the role description long-term need, and short-term fiasco creates a perception of lower value of the individual, even though they were not hired to fill in these unique architecture technical deficiencies. Typically what happens here, is the junior technical staff will begrudgingly fill in the gap, wonder what the “old guy” is doing to earn such a salary, and take longer to team build. Technical architect will team build great with the team, but struggle antithetically with the upper levels, especially in handling the drivers, poltiical sensitivity, and explaining the benefits of the architecture, and design in simple speak. 

“The Bobs” –  As office space pointed out, when you bring in organizational development, or architects considering new implications to process, workforce, technology, and investment, there is going to be assumptions that the “short-timers” are in it to get the deliverable done, and get out, and not worry about the collateral damage. That is their performance driven job. They help the executive organize, see alternatives, model, get technical, management, and leadership expertise, and they are gone. As well, it tends to make any internal architects look bad, as they will be moving at a pace that makes the underlings and overlings ask – “why couldn’t you have done that?”. Now it gets the job done, but definitely is more of a clean-up technique than a bonding and corporate unity experience.

Alternative solution to “After the first two projects, what is next?”

Essentially we have pointed out some major challenges to hiring – but more importantly – to the architect as a full-time employee model?

  • How can you keep good talent? How can you retain the investment and knowledge?
  • Are you going to want the role to expand? 
  • How can you get both the architect who grows with the company and solving low-hanging fruit tactical hands-on issues?
  • Do you have enough work to keep the architect adding value based on what you are compensating for full-time employment?
  • How can the architect keep up with rapidly changing technical patterns as well as growing in leadership, management, enterprise context, and corporate subject matter?
  • How can you keep up with changing expertise while balancing the amount of change introduced to stay innovative, relevant, and moving towards stakeholder and stockholder end goals in a timely manner?

Simply put, the full-time employee for an architect position that is likely to grow with company or product will and does not work. That is too much change to ask of the architect – they have to lead change, train others in change, grow in 3-4 professional domains, all while still being interested in a company asking a lot out of them full knowing the rest of the market is buying back risk and innovation in this skill as well. Or they may be able to do it when the service footprint is small, or in project mode, but as soon as operations picks up, moves from a project to projects to program, to regional to division, on the fast ride of national or worldwide services, that is when the peter principle kicks in.

Point being, Consider other models based on where you are buying your risk

  • If you only need for next two projects, consider contract-based employee
  • If your organization is on roller coaster of growth and portfolio change, contract out consulting firms
  • If your organization has the raw talent, but need some temporary leadership, contract our consulting firm leaders to grow team
  • If you want long-term, but can’t define needs bring on consulting firm to bring in various architecture skillsets

Setup these external support (contract, independent consultants) to address 4 major things:

  • Make them earn your trust – setup a starter or bridge task – You need to connect with the individuals before you commit long-term. Give them initial tasks. Worst case, if you change your mind and want to go back to employee, you have flexibility now. Thereafter, award good work with next tasks, but appropriately longer. 
  • Be clear on what may change –  Don’t map out the roadmap for them – make them earn their purpose, but at same time, let them know what roles may be needed in future, so they have a sense of what type of architecture you may need. You wouldn’t hire a cook, then after six months after, ask if they could farm as well?
  • Define outputs – Try to avoid long-term time & materials. Maybe initially, but thereafter, be project or outcome milestone based to assure the honeymoon delivery value continues
  • Setup Lead Key Personnel – Make sure you get a team lead or lead point of contact you have written into contract/task order to escalate, report, and get status from to manage change, risk, issues, and quality. Though you typically do not get personal services contracts, unless it is just independent, you can ask for certain commitment level from A-team before they staff with a B-team – that is what you are paying for.
  • Contract Terms should be simple and clear – Clear outputs and due date from award, clear understanding of their assumptions for resources, access, team, and dependencies from you, clear either fixed price or not-to-exceed amounts, and clear indirect cost understanding (travel, other)
  • Know Executive expectations – If you know the executive is getting impatient, has high expectations, putting that on a new full-time employee may be hard. At same time, if you want to take time, build the culture, and internal skillset, building short-order  tasks to consultants will possible create adversarial relationships between employees and their bosses to show-off.

If an itch is being scratched, please take some time to review “What are Various Architecture Staffing Models” that Xentity can support.

What are Various Architecture Staffing Models

Blog post
added by
Wiki Admin

Various Architecture Staffing Models

Choose an Architect workforce model that addresses the above. Instead of full-time architect, consider the executive or director or technical sponsor for the role main question – “What will the role do after the first two projects/tasks?”.  

Architect as Full-Time Employee

RetentionQualityLevel of WorkGrowthTotal Cost
Low, Good ones move onPlateaus after two projects. No guaranteed output after first two projects. As well, ramp-up time typically more as requires more upfront trainingFull-time, even if after first two projects workload does not matchIts either a tech architect for short-term or exec. architect for long-term, rarely can you find both in one and keep them. No guarantee of knowledge transition to team/corporation.$150-200k/yr
$100-150k in salary plus 20% in benefits plus training, on-boarding every 3 years

Architect as Full-Time Employee with executive responsibilities (not necessarily supervisory)

RetentionQualityLevel of WorkGrowthTotal Cost
Increases based on add-onsKeeps Good ones around and performance-based payFull-time commitment, but workload may not match change agent value – would have to find workPerformance can only incent so much, so this is same problem as employee model$175-275k/yr
$100-150k in salary plus 20% in benefits plus training, on-boarding plus 20% in performance and/or equity 

Independent Contract-based employee Architect as near full-time or full-time

RetentionQualityLevel of WorkGrowthTotal Cost
Renew based on defined, known key result directives/areas. Typically this is one with relationship that exists so sometimes harder to let goRenewal-based to help buy-back risk on post first two projects.Can be full-time, part-time or variable (FFP, T&M) and renewal-basedCan either watch growth, change detail responsibility, or lower hours in one architect. No guarantee of knowledge transition to team/corporation.$150-250k/yr
Typically T&M models with NTE of full-time investment, less onboarding, no benefits/FUCA

Hybrid – Independent Consulting Architect to do & lead Junior Full-Time employees

RetentionQualityLevel of WorkGrowthTotal Cost
Renew based on defined, known key result directives/areas. Sometimes harder to let go if junior employees have grown attachedRenewal-based to help buy-back risk on post first two projects as well as increase corporate knowledge retentionCan be full-time, part-time or variable (FFP, T&M) and renewal-basedAssure knowledge transition and investment in growing staff

$175-275k/yr

$120-$200/hour with volume discounts. Typically more efficient than 100% full-time models

Architecture firm Consulting Services

RetentionQualityLevel of WorkGrowthTotal Cost
Renew and include key personnel requirementsHave more access to various executive, enterprise, solutions, technical, data, process, and services architecture as well as additional deeper tech-reachbackCan be individual or multiple full-time, part-time or variable (FFP, T&M) and renewal-basedCan vary investment in different architect types that change as the fast disruptive

$75 to up 300k/yr for equivalent of 1 FTE

Higher cost per hour, less hours

Recommend 3 to 8 $25 to 75k task order in first year max.

Interim Consult/Contract

RetentionQualityLevel of WorkGrowthTotal Cost
Known end with options to extendsame as non-employee options aboveTypically Full-time as it is placeholding for full-time positionVaries by model chosen above – contract, independent consultant, consulting firm$125-300k/yr
As well, given the task order is more long-term, and has authority as would employee, this reduces the “consulting” model tensionVaries greatly and sometimes requires hefty headhunter fee

 

Xentity can support any of these models in contract-to-hire, staff augmentation, or various consulting capacities.