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.

Xentity powered team wins VA Outreach Video work

Blog post
added by
Wiki Admin

Xentity, as subcontractor to PhaseOne Consulting Group, will lead the end to end video production of the Alaska Veterans and the value and benefit the VA has played in their lives in hopes of boasting enrollment of rural residents as part of an overall outreach toolkit for rural outreach in Alaska. 

The approach presented was to lead strategy development, design, and script-writing of a High-Definition Video and execute production shoots on-site in Alaska and execute a high-quality post-production effort for distribution. Xentity is excited to be part of this team and assist the Department of Veteran Affairs in improvement of access and visibility to its benefits services.

 This solution fits into Xentity’s capabilities Media Production capabilities with its FlipFlop Production branded services.

The Four V's of BigData – Variety Veracity Velocity Volume

Blog post
edited by
Matt Tricomi

If we are simply talking about lots of retail data, lots of sales data, lots of management data, lots of metadata, we aren’t talking BigData. Though for some reason, those data are going through and into the new architectures. Yeah, sure the retail, defense, and intelligence worlds have been sifting through huge data stores for years. 

But the marketing coined term BigData is not just referring to the Volume of the data. There are 4 V’s of big data . We have been enjoying using as learned through our information exchanges and partnering with IBM.

The first two v’s focus on mission side: Variety and Veracity

Variety (how many categories of data does it cover) includes as well technology (sources, formats (

(e.g. numeric, text, objects, geocoded, vector, raster, structured, unstructured – email, video, audio, etc.), methods) and legal  (complexity, privacy, jurisdiction). Essentially working with various types of data including various dimensions (temporal, geospatial, sentiment, metadata, logs, etc.) and 

Veracity (understanding authority of data) includes known data quality, type of data, data management maturity so that you can understand how much you can trust the data is right and accurate

The other focus on the speed and amount: Velocity and Volume

Volume (how much data). – Capturing, Processing, Reporting and managing a large volume of data

Velocity (how often it changes or real-time) – Analyzing and exploiting lots and lots of new data in real-time

Changes to the V’s over the last 15 years

 

 

Veracity is the newer one. The concept of data quality has always been the orphaned step-child. It is the I in IT. Its the part of the iceberg under the water. All IT vendors want to sell speed, and handles lots of data, and some commodities of variety support, but once sold, you are on your own (or $300/hour for mission customization). But, we are happy to see IBM got there and added it.

As of late, Value has been introduced as well. Paraphrasing the spanish article, even if you can produce information, is there is no real action that can be done with it, its not Valuable to the organization.

Then again, some have accused IBM of stealing the V’s from 2001 Gartner V’s development . This V-gate controversy :

Nonetheless, if anything it proves that its a concept that is worth fighting over meaning and digging into it, you see it has its merits. 

Xentity makes the Hispanic Business Top 500 List – again

Blog post
edited by
Wiki Admin

For 2012, Xentity Corporation has been ranked again in the Hispanic Business Top 500. Xentity jumped 18 places to #466 and is 1 of 8 from Colorado and only company in Golden. In 2011, there were only 10 companies in Colorado, and only Xentity based in Golden, Colorado on this list.

This list has been tracking and ranking Hispanic Businesses for 30 years. As noted on HispanicBusiness.com, Hispanic Business research staff gathered data for the listing of the 500 largest Hispanic-owned companies in the United States from a company profile form returned by the companies themselves. Companies included in the 500 must show at least 51 percent ownership by Hispanic U.S. citizens, and must maintain headquarters in one of the 50 states or Washington, D.C. Principals must be U.S. citizens. Companies must submit revenue figures based on line 1(c) of their corporate/partnership tax return. The revenue figure must be submitted on a signed form verified by the CEO, CFO, or a CPA representing the company. 

Press notes in:

http://www.bizjournals.com/denver/news/2013/06/24/colorados-top-hispanic-businesses.html

http://www.metrodenver.org/files/documents/metro-denver-economy/monthly-econ-summary/2013/Jul13EconSummary.pdf


Will geoscience go for a shared service environment

Blog post
edited by
Wiki Admin

Will geoscience go for a shared service environment?

As the previous “How can we help geoscience to move their data to shared services” blog noted, unless we align the stakeholders, get a clear line of sight on their needs, and focus on earning trust and demonstrating value, the answer is no. But let’s say we are moving that way. How do we get started to fund such an approach?

Well, first off, the current grant and programmatic funding models are not designed to develop shared services or interoperable data for the geosciences.  Today, there are many geoscientists who are collaborating between disciplines and as a result improving the quality of knowledge and scaling the impact of their research.  It is also well established that the vast majority operate individually or in small teams.  Geoscientists, rightly so, continue to be very focused on targeted scientific objectives and not on enabling other scientists. It is a rare case when they have the necessary resources or skills.  With the bright shiny object of data driven science /Big data; do we have the Big Head wagging the body of the geoscientist community?  Xentity sees opportunities to develop funding strategies to execute collaborative performance-based cross discipline geosciences. It has been this way since World War II really expanded upon its war-time successful onesy-twosy grants to universities since then. There has been some movement towards hub and spoke grant funding models, but we are still out to get our PhD stripes, get our CVs bigger, and keep working with the same folks. I know it is a surly and cynical view. OK, the real is they are doing amazing work, but in their field, and anything that slows down their work, for greater good, is lacking incentive.

Also, there are few true shared services that are managed and extended to the community as products and services should be. Data driven science, which is out fourth paradigm of science, has been indirectly “demanding” scientific organizations and their systems to become 24×7 service delivery providers. We have been demanding IT programmers to become service managers, scientist to become product managers, or data managers.  With a few exceptions, it has not worked. Geoscientists are still struggling to find and use the basic data/metadata, produce quality metadata (only 60% meet quality standards per EarthCube studies) for their own purposes, let alone making the big leap to Big data and analytics. Data driven science requires not only a different business or operating model, but a much clearer definition of the program, as well as scientist’s roles and expectations.  It requires new funding strategies, incentive models and a service delivery model underpinned by the best practices of product management and service delivery.

Currently, and my favorite, there is limited to no incentive for most geoscientist to think beyond their immediate needs.  If geoscientists are to be encouraged to increase the frequency and volume of cross-discipline science, there needs to be enablement services, interoperable data and information products that solve repetitive problems and provide incentive for participation.  We need to develop the necessary incentive and management models to engage and motivate geoscientist, develop a maturity plan for the engineering of shared geoscience services and develop resourcing strategies to support its execution. Is this new funding models, new recognition models, new education, gamification, crowdsourcing, increasing competition, changing performance evaluation? Not sure as any changes to “game” rules can and usually introduces new loopholes and ways to “game” the system.

The concept of shareable geoscience data, information products and commodity or analytical computing services has an existing operating precedent in the IT domain –shared services.  Shared services could act as a major incentive for participation.  An approach would identify the most valuable cross cutting needs based on community stakeholder input. The team would use this information to develop a demand driven plan for shared service planning and investment. As an example, a service-based commodity computing platform can be developed to support both the Big Head and Long Tail and act as incentive to participation and perform highly repetitive data exchange operations.

How does one build and sustain a community as large and diverse as the geosciences? 

The ecosystem of geoscience is very complex from a geographic, discipline and skill level point of view. How does one engage so diverse a community in a sustainable manner?  “Increased visibility of stakeholder interests will accelerate stakeholder dialogue and alignment – avoiding “dead ends” and pursuing opportunities.” The stakeholders can range from youthful STEM to stern old school emeritus researchers; from high volume high frequency data producers of macro scale data to a single scientist with a geographically targeted research topic. It is estimated that between 80-85% of the science is done in small projects.  That is an enormous intellectual resource that if engaged can be made more valuable and productive.

Here is a draft target value chain :

The change or shift puts a large emphasis on upfront collaborative idea generation, team building, and knowledge sharing via syndication, and new forms of work decomposition in the context of crowd participation (Citizen Science and STEM).  The recommended change in the value chain begins to accommodate the future needs of the community.  However, the value chain becomes actionable based on the capabilities associated to the respective steps.  Xentity has taken the liberty to alliteratively define these four classes of capabilities or capability clusters as:

Encouragement, Engagement, Enablement, and Execution.

Encouragement capabilities are designed to incentivize or motivate the scientist and data suppliers to participate in the community and garner their trust. They are designed to increase collaboration, the quality and value of idea generation and will have a strong network and community building multiplier effect. 

Questions

Capabilities

  • How can new scientific initiatives be collaboratively planned for and developed?
  • How can one identify potential collaborators across disciplines?
  • How can one’s scientific accomplishments and recognition be assured and credited?
  • What are the data possibilities and how can I ensure that it will be readily available?
  • How can scientific idea generation be improved?
  • Incentives based on game theory
  • Collaboration, crowd funding, crowd sourcing and casting
  • Needs Analysis
  • Project Management and work definition
  • Credit for work Services

Engagement Capabilities include the geoscience participant outreach and communication capabilities required to build and maintain the respective communities within the geoscience areas.  These are the services that will provide the community the ability to discuss and resolve where the most valued changes will occur within the geosciences community, who else should be involved in the effort?  

Questions

Capabilities____________________

  • What participants are developing collaborative key project initiatives?
  • What ideas have been developed and vetted within the broadest set of communities?
  • Who, with similar needs, may be interested in participating in my project?
  • How can Xentity cost share?
  • Customer Relationship Management
  • Promotions
  • Needs Analysis
  • Communications and Outreach
  • Social and Professional Networking

Enablement capabilities are technical and infrastructure services designed to eliminate acquisition, data processing and computing obstacles and save scientist time and resources.  They are designed to solve frequently recurring problems that affect a wide variety and number of geoscience stakeholders from focusing on their core competencies – the creation of scientific knowledge. Enablement services will have a strong cost avoidance multiplier effect for the community on the whole if implemented and supported.

Questions

Capabilities

  • How does one solve data interoperability challenges for data formats and context?
  • How do I get data into the same geographic coordinate system or scale of information?
  • How can I capture and bundle my Meta information and scientific assets to support publication, validation and curation easily?
  • How can I get access extensible data storage throughout the project lifecycle?
  • Where and how can I develop an application with my team?
  • How can I bundle and store my project datasets and other digital assets later retrieval?
  • How can I get scalable computing resources without having to procure and manage servers to complete my project?
  • Workflow
  • Process Chaining
  • Data Interoperability
    • Data transformations
    • Semantics
    • Spatial Encoding and Transformation
    • Data Services
  • Publishing
  • Curation

Syndication

Execution Capabilities are comprised of the key management oriented disciplines that are required to support shared infrastructure, services or to help evolve a highly federated set of valuable assets “edges” to be more useable and valuable to the evolving community over time.

Questions

Capabilities____________________

  • How do we collectively determine what information might require a greater future investment?
  • What are the right incentives in the grant processes?
  • What are the future funding models?
  • What models should be invested in?
  • Which technologies should be evaluated for the shared assets?
  • What upcoming shared data or technology needs are in common to a large number of participants?
  • Governance,
  • IT Service Management (ITSM),
  • Product Management,
  • Performance Management,
  • Requirements Management,
  • Data Management,
  • Data Supply Management,
  • Data Life Cycle Management
  • Funding
  • Grants and processing

So, why did we develop these classes of capabilities? 

They represent, at the macro level, a way to organize a much larger group of business, operating and technical services that have been explicitly discussed in NSF EarthCube efforts over the last 3-4 years. We then been derived these outputs from analysis and associate them to the most important business drivers. Check out this “draft” relationship of capabilities drivers and rational 

 RationaleDrivers
EngageThe best way to create communities and identify common needs and objectives, begin to build trust and value awareness; bring the respective communities into an environment where they can build out their efforts and sustain collaborative approaches.Agency (how to navigate planned versus emergent change), intellectual property rights, infrastructure winners and losers, agreement on data storage, preservation, curation policies and procedures, incentives to share data and data sharing policies, and trust between data generators and data users.
EncourageThe best models to incentivize scientist’s and data producers to participate and collaborate. Xentity have developed game theory based approaches and large scale customer relationship management solutions Social and cultural challenges: Motivations and incentives, self-selected or closely-held leadership, levels of participation, types of organizations, and collaboration among domain and IT specialists)
EnableThe most costly data processing obstacles – The lowest common denominator – highest impact problem.  A common problem found in shared service environments. We have developed enterprise service analysis tools for cost benefit for the DOI geospatial community, so we have seen this work80% of scientist data needs can be expressed as standard data product, and 80 % of scientist time is spent getting data into proper form for research analysis
ExecuteA governance model that will increase the “edge effect” between the legacy and future capabilities and a very diverse set of communities. Simple planning capabilities that empower scientist to work complex cross disciplines ideas amongst themselves, define work and coordinate with the power of the crowd. We have designed collaborative environments and crowd based frameworks for data collection and analysis with corresponding performance management system.Conceptual and procedural challenges: Time (short-term funding decisions versus the long-term time-scale needed for infrastructures to grow); Scale (choices between worldwide interoperability and local optimization);

So why don’t we do it?

Well, this does introduce an outside approach into a closed knit geoscience community who is very used to solving for themselves. Having a facilitated method from outside consulting or even teaming with agency operations who have begun moving this route for their national geospatial data assets is not seen as something fits their culture. We are still learning of hybrid ways we can collaborate and help the geoscientists setup such a framework, but for now it is still a bit foreign of a concept, and while there is some awareness by the geoscientist community to adopt models that work for other sectors, industries, operational models, the lack of familiarity is causing a lot of hesitation – which goes back to the earn trust factor and finding ways to demonstrate value.

Til then, we will keep plugging away, connecting with the geoscience community in hopes that we can help them advance their infrastructure, data, and integration to improve earth science initiatives. Until then, we will remain one of the few top nations without an operational, enterprise national geoscience infrastructure.