Top 5 low hanging fruit to not bungle IT Procurement

Blog post
added by
Wiki Admin

IT Procurement as been a hot button issue as one of the largest civilian IT projects – DoD IT-sized in a way – was “bungled” in almost every phase: Cost went 6x original bid, architecture was overly complicated, no system integration concept, no end to end software or data lifecycle management end, and no quality acceptance procedures, criteria, incentive or the like.

We all know some or all those problems. But as the FCW article cites: “Bungled launches didn’t start with HealthCare.gov.” Its everywhere. Its government, commercial, non-profit, everywhere.

Of course, at Xentity we are biased – we believe in take your medicine now approach – design upfront, register and buy back the risks, and then move into agile design, rapid development, and iterative launch as relevancy and the market allows.

FCW notes there is “considerable agreement on how to go about overhauling the procurement system…” but they have some consensus on 5 key actions:

1. Do a better job on defining desired outcomes upfront
2. Improve the training options for the federal acquisition workforce to put them on an even footing with vendors
3. Give agency CIOs more budget authority
4. Avoid lowest price, technically acceptable contracts on large innovation-heavy projects.
5. Use agile development strategically and mainly when a project does not require a log of interaction with legacy systems.

To too our own horn, these are many of the fundamental goals that Xentity staff and solution focuses on. In reply to those five items:

1. This is our main emphasis on the design the concept of operations, and requirements for the SOW, and registering the risks and knowing them ahead before procurement. Still allow vendors the flexibility for logical and technical design, but know upfront the various concepts that may come back and know how to score them
2. our fedbiz.xentity.com business management specialists service integrated with our architecture practice allows us to help bring contracting and procurement specialization into helping understand how vendors who may respond based on market analysi results will respond to certain requirements or solicitation frameworks
3. We are setup to help advise CIOs on enterprise portfolio, architecture, capital planning, and segment adoption of CIO services and solutions
4. We agree that the LPTA method does not work for acquiring design, planning, creative, and solution management services. LPTA beltway experts tend to game the systems by replying to architect positions with application developer rates for architects on initial task order and techincally it is acceptable, and the rates are 30% better. But its a lot like asking a cook, “can you farm?” Technically, the cook probably could, but wouldnt you want someone familiar with the subject matter expertise of agriculture economics, farming lifecycles, key risk and success factors or someone who knows food. The solution ends up costing more as MODS occur, the app developer gets replaced, and government pays the cost for missing deadlines and scope creep.
5. This is a biggie! Marketing hyped up Agile as the “it slices, it dices, it julienne’s!”. It is great for new transaction systems on abstracted solutions. It can be good for some feed ETL or integration. But, when you have an immovable object, it doesnt matter how agile you are. In those cases, you need to conduct architecture design, concept of operation alternative analysis, business case evalution, requirements definition, and register and buy back risk.

All this said, we are very happy to see this attention back onto better design and defin up front. Of course, being in this field, it is always nice to be noticed and knowing we are on the right track. More importantly, we believe it is what is needed and the right thing to do for investing wisely with our citizens or customers money/assets.

Xentity awarded IT IDIQ from State of Colorado

Blog post
edited by
Wiki Admin

The State of Colorado’s Governor’s Office of Information Technology (OIT) has awarded to Xentity an IDIQ Master Agreement for business services

This master task order contract (MATOC) is a result of an award under RFP-001-JG-14 for Computer Programming, Consulting Services, and Business Services involving Cloud Solutions. 

In the Fall of 2013, The State of Colorado’s Governor’s Office of Information Technology (OIT) sought proposals to identify Implementation Services (“Implementers”) for business services involving cloud solutions by Salesforce.com, Google, and Perceptive Software (Perceptive), and other emerging technologies. 

  • The award is for an Enterprise Agreement, as a multi-contract award IDIQ
  • base period of 5 years and 5 consecutive 1-year renewal options
  • an initial $10 million maximum contract amount/ceiling.  
  • Task orders can be issued by multiple sponsoring state agencies.

Xentity has previously won and supported contracts for the State of Colorado with the Department of State and has worked closely with the Office of Information Technology.

Xentity’s Services can be ordered from any of the Colorado Agencies via this contract

Scope Include:

  • Task Order Technical Management
  • Agile Project Management
  • Solution Architecture
  • Architecture & Governance Support
  • Cloud Solution Development / Database Support
  • Portal & Development/Database Support
  • Application Development Support
  • Quality Assurance / Customer Support
  • Transition Support
  • Disaster Recovery/COOP Participation
  • Best Practice Group Support/Participation
  • Outreach Strategy and Support

Positions include: Project Manager, Technical Consultants, Architects, Architecture Analysts, Management Analysts, Solution Architects, Enterprise Architects, and Communications specialists for Branding, communications, design, and strategy 

More to come on how to access Xentity services off this contract.

 

Piling On HealthCare.gov

Blog post
edited by
Matt Tricomi

Washington just can’t catch a break, eh?. Debt Ceiling. Sequester. Shutdown. And now an epic fail of a single portal solution that provides the primary access to the new healthcare access law.
Love it or hate the law, the model for the electronic access provision is definitely an epic fail of a rollout.
What else is an architect to do if we can’t pile on the fiasco, offer opinion, while at same time, we are hoping to catch someone’s attention or get some sense someone is thinking about it from the design point of view, as it appears the media, hearings, and threads are not hitting on, at least, where we were hoping the discusion would land. Its a bad design. I’m not commenting on the policy part – the pundits do enough of that. I’m commenting on the architecture itself. It appears a poor design.
The following captures our internet sleuthing, colleague discussions, and our current deductions.
This is an evolving blog, as its more of a case study than a daily diary. Its a bit in draft form, but a way to begin to pin the story together. Apologies for the language typos and pre-publish ready state, but figured this is so fast moving and important, that I wanted to add to the dialog, and not simply leech after with 20/20 hindsight.

UX and Web Design is fine – Its not the front end

Now much fanfare has gone to the “web site” glitches. It was written about back in June by Alex Howard in the AtlanticI had the pleasure of connecting with Alex during data.gov work back in 2010 and off and on, we correspond on social media occasionally. I have a respect for his writing, what he follows, and have found generally that he is spot on with bringing collaboration across traditional boundaries into the world of information and technology. That said, I may be a bit biased. 

Here are just a handful of articles done on the healthcare.gov performance:

http://www.websiteoptimization.com/speed/tweak/healthcare-gov-analysis/

http://apmblog.compuware.com/2013/11/04/diagnosing-obamacare-website-heathcare-gov-still-lacks-basic-optimizations-before-it-can-mature/

http://www.mardesco.com/blog/website-optimization-and-healthcare-gov/

http://www.conversionmax.com/healthcaregov-what-went-wrong/

Its the same thing as above – minify, compress, order your scripts/CSS, cache. Yep, the same things back in 1999, just a MUCH more powerful scripting and style processing capability. 

Point being, this client-side tweaking is all REALLY good practice, especially for large sites with large traffic. Every little bit of debris cleanup helps. But, whatever fix is done, there needs to be a balance of the true timeline issues. It appears that the problem is primarily a server-side architecture problem . There were/are definitely several issues with the front-end performance as the above articles suggest. Its easy for the web technophiles to do, since most of the web processing is on the client side – in your browser and tools (i.e. hit F12 on a PC in Chrome or do  YSlow plugin for Firefox) are easy to use or websites like what Google Analytics does can analyze performance, content safety, usage statistics and so much more. Point being, are you going to put more resources to fix the leaky faucet or the gushing, gaping hole in the water main first?

Now, Alex only reported on the developments of the front end and UX component. There is deserved high praise on Prose.io, Jekyll, open source concepts, garage organizations breaking beltway development stereotypes, and persona development as a way to develop the navigation for this brand new pattern.

But, the point is, the UX and web design part is fine and and dandy. Alex was right in June and still is. Its the same architecture I did for united.com back in ’99, just different tech. Have a CMS, cache it, distributed over 4 servers west/east. When 9/11 hit, my site was only airline site (check internetwayback machine) and call center that stayed up. So, this model for hc.gov is fine. The UX caching is fine. 

He didn’t report on the back-end part. Mind you, this part is under reported and the complexities of the iceberg under the water has been mis-understood. A lot of folks have joined the form of internet bashing snarkiness and bashed Alex’s journalism and attacked his integrity as a bandit of sorts. In other articles, I did see some purist nerd talk on some of poorly grouped javascript or heavy, some bad code, added some extra callbacks, and wasn’t as static as it should have been, it was quick to determine that was minor. 

I felt pretty bad for him on the article, and generally as a citizen, embarrassed, so like many of us architect weenies, I dug into it as many other colleagues have. Hey, regardless of politics, we all want a working country. 

Why the logic for real-time data aggregation architecture?

Just like the Tacoma Narrows Bridge didn’t fall because the construction contractor failed, it was the architecture forgot one piece of logic – the wind in this river was very strong. There was nothing to dampen the flow, and when the wind force blew, it blew the bridge passed and near its natural frequency (think rubbing your finger on a wine glass), those vibrations shattered the bridge. It was built to specification by the contractors, but the design was horrible because it had flawed logic.
OK, where is the parallel. So if its the back-end problem for healthcare.gov, where is it? My background and recent work on “hero” architecture was also excited to hope it was a minor performance issues that could be fixed by some horizontal scaling of servers. They did that, no major fix. Maybe it could be some technical server or software tuning – no luck. That only leaves bad logic.

Now it appears possibly the contractor did have faulty construction in that their wasn’t enough foresight to do more parallel testing, load testing, integration testing and the “7 steps of doneness“. The architects came out and said it today. Though that sounds a little passive aggressive now, as an architect of a building, would you say that after the bridge collapsed? Sounds like either buckpassing or gag order or droopy dog, no on is listening to me. 

But even that would have been able to be reported out by now. So, aside from the obvious lack of discipline for engineering failures which is the civil engineering equivalent to the Tacoma Narrows Bridge, what logic am I talking about.

I believe it comes down to the architecture logic in this case, likely multiple areas. They treated the architecture like a controlled real-time MIS distributed system on data that has not been standardized or proven to be easily integrated through the test of time
 

Bad Logic: It appears they are responding to business rules that ask for real-time queries?


Why are they doing this? Is Healthcare.gov is following the KAYAK.com or Orbitz.com data aggregation model? In airlines, rates could change any minute, airlines have proven APIs over a decade of time-tested improvements, and those smaller airlines get screenscraped and KAYAK spends dollars keeping those scrapers up to date – just like when mainframes used to be scraped for client-server integration. Airline is a huge industry, they put their paper ticket to eticket on the line and it took a decade to get to this model. Then again, USA Today put out an article noting that Healthcare.gov is not alone on high-tech blunders:

United, Continental merge computer systems

March and August 2012

United Airlines had problems with its reservations system in early March after it switched to Continental’s computer system as the two airlines merged operations. Passengers complained as United struggled for several days to fix problems. In late August, the airline’s computer system and website went down causing problems with reservations, ticketing and check-ins.

This of course made me smile a little bit since they took down my architecture I did for united.com since they decided to move to Continental’s toolsets mostly because United needed to get out of Apollo mainframe (so says word on the street). So when they through [my] proverbial baby, then 12 years old and still well respected and award-winning out, with that, it did make me smile. But, point being, even big moves in private industry will happen in this type of architecture.


While I appreciate the importance of up-to-date comparisons, cant this stuff be pre-loaded? Why are we bucket brigading this information? Did they do this because they got caught up with the fanfare of the neat front-end – which again is slick, but its a small part of the project. Its the book on the cover that gets people there and comfortable and to have a good interior design user experience. But if you cant get a cup of coffee in Starbucks, does that matter?
I wonder if it needed to be this way.  When I heard about the queries real-time crossing statelines, which meant that all the quality validation would require quality handshake, in real-time from each source where each time a different provider, state, or other governing data source, that would require a whole different set of rule base to validate. Each state, provider, etc. operates differently and to expect that real-time is quite an aggressive and bold feat.
At same time, is that required? Imagine doing a bucket brigade through 10 points for one bucket to put out a fire, some water will be spilled, but if you simply put more people/power in between, the spillage doesnt matter. That is why it works for normal web service models which has made Twitter, facebook, and many other Services used in other apps work so well. Its a simple single source of data.
Now, pretend there are 50 different types of twitter imitators, all with different approaches to tweeting, different data about the user or the tweet (aka metadata), different ways they setup the service call, and under different state laws to share that information. This is healthcare.gov.
My idea here isnt overaly novel. Check out gov.uk and MongoDB’s article – Reinventing Data Management for Government Websites which discusses just this theory:
HealthCare.gov faces challenges like aggregating volumes of data and building an efficient system to meet citizens’ needs. An agile database like MongoDB could have helped HealthCare.gov to scale, remove redundancy, and potentially reduce the cost (estimated to be at $292 million so far) (WaPo article) of both creating the site and dealing with the fallout of its failure.
I haven’t reached a point of validation yet, but it sure seems like the separately developed service handshaking across these disparate sources would cause integrating data that was created, formed, provided, and published under such different bucket brigade handlers, that it would be like having a bucket bridge coming out of a lake and an ocean, and expect only fresh water and the extra salt water magically goes away.

Why not pre-stage the queries?

I guess I’m asking still – why do they need to aggregate real-time? Why can’t they pre-stage the calls? Are they really updated every minute?


You make pre-staged products, where in between each organization, you validate the quality, get it ahead of time, or design-time, so then your run-time call can call the validated source which can be updated every week, day, 15 minutes, etc. and different of each feed. Then when new feeds come in, the separate pre-built maps or indices are auto-updated to make and optimize the comparison experience too, and even setup the possibility to help inform what the comparison mean or simply make matter of fact statements about the comparisons (not advice, but make obvious the differences). Google has proven this model. Its just reading content. And with the knowledge snippets in Google now on the right, you can ask it basic factual questions now. They can compare and its all hitting a local, validated, appropriately up to index that can scale, elastically on the cloud, that is proven fast – Google has proven that.

We recently did this same thing for a must be remained anonymous major Government agency. They had their search calls call the traditional RDBMS which is better at searching on a specific record and returning in simple, non-high computational queries. Instead, we asked, can you move 90% of the search into a NoSQL solution. It can load hundreds of millions of records in minutes, do all the pre-calculations to make for a smarter search – like how google knows what you are typo before you do, it can handle typo, many facets, drilldowns, etc. I believe KAYAK has moved this direction as well, but can’t validate, to optimize its search experience.

This is why the twitter, facebook, and other popular highly used service APIs work. They designed their SiM, and now there is a massive ecosystem of sub-applications, sub-markets, aftermarkets. HC.gov did not do that, it took a YAGP (yet another government portal) architecture technique, parted the scoping out like for a battleship. There wasnt enough consideration for patterns like more design-time pattern integration vs. run-time pattern integration (which is something I recently architecture prototype for NARA adding a NoSQL “index”, if you will, in front, so the query part was fast, but the transaction part got passed to the traditional RDBMS, then if updated, it did a millisecond sync back with NoSQL.

Now for the Blame Game: In contracting, investing in architecture is still not a requirement, so its a liability to bid it that way. 

It was divvied to over 50 contractors, and outside of a PMO, there appears to be no enterprise service integration patterns concepts are part of the leadership team. I saw a PMO, but they usually manage the production, not the architects of what needs to be produced. We can throw CGI Federal under the bus all we want, and whomever did the PMO, but it sure seems like the requirements and team did not have a solution or architecture integrator as one of the roles. Someone(s) overseeing the Service Integration Model – call it Enterprise Service Architect, Sr. Solution Architect, Architecture Review Board/Governance – to advise on design risks, maintain risk weights and let the PMO know where risk is at escalation points. 

I do know in contracts, if you are believing you could win if you could shave 3% off the contract, the first thing to go is usually the higher end rates. Those rates are usually quality focused. Those typically are those on architecture, design, strategy. Typically government contracts do not write that in, or if it is, it is written in a more compliant way. Contracting Officers are not in a position to review whether a subjective concept such as a proposed architecture is better than another and Contracting process review boards for IT have not adopted concepts like in civil engineering architecture concept review boards. Given that, having a higher quality architecture solution component is not seen as differentiator, since it doesnt check a box, typically integrators will drop that high rate position, and wallla, you have just undercut competition by 2-4% on the bid. 

By the way, don’t get hard on the contractors only. The same goes for the writing of the contracts. Contracting Officers do not have a way of knowing if the technical requirements is asking for are sound or the best. And they have stated on occasion they like to leave it open to allow the contractor to come back and tell them “how”. While this is fair to let private industry offer best solutions, there should be architecture principles that are put in the contract to guide how they can answer, and thus less subjectively how they can assure robust architecture, for instance, without just saying “it will be a robust architecture”.


But as we saw, when you don’t buy back the risk up front, and the design changes, the cost balloons, which it did. Today, the reports are saying contractors are blaming the government after a few weeks of government throwing “greedy” contractors under the bus. I say its not greed, but a broken procurement process. We have blogged for years, and built our practice around this principle – We can approach architecture for other implementers . 

For a large majority of consulting companies both design and implement for ALL projects.  Though profitable for many firms, the best design can end up biased towards the agenda of the implementer which may be to sell more components, get more bodies. Now, we have the capability to implement architecture, but our end goal is not to design an architecture that is for us to implement, but an architecture that is implementable. 

Many times, the client knows that the implementer will design with a bias, so the client chooses to or must design blind without considering the maturity of what an implementer can provide. In those cases, we can come in, architect, and be a third party to help do the concept, design, and design the requirements and performance work statement basis.

This approach with these services buy-back risk to your implementation and increase the likelihood of achieving your metrics and goals.


11/1 Note: A colleague forwarded me two WSJ articles that discusses Fixing Procurement Process Is Key to Preventing Blunders Like Healthcare.gov and Procurement Process is Government’s IT Albatross which only adds fuel to the fire. These blogs uses Clay Johson’s Fix Procurement Manifesto as its guide. I agree with many points in Mr. Johnson’s manifesto and his points, but I don’t agree with the author’s understanding. The author boiled it down to make procurement easier to get new tech. That sounds well and good, but as a colleague who was formerly in the OMB said a few weeks back, if you add any tech to a broken process, it will only make it worse. And it did. So, I think it will not only take time to fix Agency Leadership as Johnson notes, and the author cites Former OMB CIO Kundra as a key, but also, the general public understanding of how technology and business transformation works. The author and agency leadership compare healthcare.gov, a solution that involves data exchange, policy oversight, and manages millions of transactions to an Operating System flaw in an iPad which requires fix once, deply many. These are very apples and oranges conversations – one is commodity technology, and other is automating multiple decades of policies on top of policies. Until we can help educate the differences in complexity, we won’t be able to achieve the aspects of Johnson’s manifesto as well as help understand the right architecture to invest in PRIOR to letting a contract.

-mt

Xentity holding Methodology Development review for ACT-IAC, Smart Lean Government

Blog post
edited by
Wiki Admin

Xentity, Methodology Development example (2002-2008 How TAA grew to MBT grew to OMB FSAM)

Over 6 years, it took several iterations of method, applying to projects scaling up method scope, application on programs/segments, lots of info sharing, and then promotion to base of FSAM. This is not to direct the Content of the ACT-IAC, Smart Lean Government (SLG) efforts, but how the method got developed, training material built out and trainer, how the team went out information sharing, promoting, and then helping apply to support true business transformation and modernization blueprints.

Summary of Objectives:
– Covered how Xentity and partners supported the Dept of the Interior iterate/develop the “Methodology for Business Transformation” showing some sample deliverables, templates, and visuals
– Discuss how we iterated from Bureau TAA (02-03) to DOI MBT (04-06) to OMB FSAM (07-08) through maturing from bureau, to agency, to federal through not only iterative method development, but through applying in iteration. First a few blueprints at bureau, then four at agency cutting across different driven blueprints (legal, organization development, target architecture, and shared services), then improving the method, and doing more blueprints, then doing more communications and training, and finally, promotion to OMB through collaborative integration with other methods.
– Cover lessons learned, critical success factors (i.e. framework agnostic, mapping to frameworks, culture understood, tested in 3 cycles of blueprints, breaking into services, first attempted foray into doing as NGO in 2006)
– Pitfalls (i.e. overselling, under training, lacking certification, didn’t emphasize earlier phases, limited bureau accountability, perception and politics, moving to FSAM – losing key aspects, calling it method instead of approach, perceived waterfall and not presented situational, training/maintenance budget limits)
– Cover things we would do now differently (i.e. wiki, more examples, more new Media communications)

Related Xentity links:

 

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.