We’ve now run enough Connect projects to see the pattern. The ones that succeed do so because certain things were in place before we ever opened an IDE. The ones that struggle are struggling because those same things weren’t ready. We can usually predict the outcome by asking five questions before the project starts. Here they are, and more importantly, here’s what to do if any of the answers is no.
1. Is Pro Cloud Server deployed and current?
This is the infrastructure question, and it’s the most fundamental. Pro Cloud Server is the engine that runs EA GraphLink. Without Pro Cloud Server, EA GraphLink cannot operate. Without EA GraphLink, Kernaro cannot operate. Without Kernaro, Connect cannot deliver the AI-assisted modeling that makes the whole system valuable.
We’ve found that this is the most common infrastructure gap. Teams have deployed Sparx EA on-premises or in their own private cloud, and they’ve optimized for user access and collaboration. They haven’t deployed Pro Cloud Server because they didn’t see an immediate need for it. Then they come to Connect and discover that the entire architecture depends on it.
What this means if the answer is no: your integration project is blocked on infrastructure work that takes weeks to months, depending on your environment. This isn’t something Connect can work around. It’s a hard prerequisite.
What to do about it: start the Pro Cloud Server deployment immediately. Don’t wait for the Connect project to begin. Involve your infrastructure team now. The deployment itself is well-documented, but it needs planning, provisioning, and testing in your specific environment. Getting this done before your Connect engagement begins means you can use your time with the integration team to actually build the integration, not to wait for infrastructure.
2. Is your MDG Technology profile defined and documented?
This is the governance question. An MDG Technology profile defines the structure of your architecture domain—what element types are valid, what properties they have, what relationships are allowed, what stereotypes apply. Without it, you have a repository full of data. With it, you have a repository full of architecture.
EA GraphLink can work without a defined MDG profile. It will expose your repository’s raw schema data to your integration layer. But that raw data doesn’t answer business questions. Your business stakeholders don’t care about tables and columns. They care about services, capabilities, applications, technologies, and how they relate. An MDG profile is what translates the raw schema into architecture language.
We’ve seen teams try to iterate the MDG profile as part of the Connect project. This creates a cascading problem. The integration can’t be tested meaningfully until the profile is stable. The profile can’t be stable until you’ve thought through what it needs to express. You end up testing integration logic against a moving target.
What this means if the answer is no: your Connect project becomes a discovery project first, a build project second. You’re not just building an integration. You’re defining what your architecture language is, then building the integration to speak that language. That’s valuable work. It’s also six to twelve weeks of work that most teams don’t budget for at the outset.
What to do about it: define and document your MDG profile before you start Connect. Work with your architecture team to answer: what element types do we model? What properties do they have? What relationships are valid? What stereotypes do we use? Document the answers. Test the profile against a few existing models to make sure it actually describes the architecture you think you have. Then bring that profile to the Connect engagement.
If you discover during this exercise that your current models don’t actually conform to the profile you’d like to have, that’s useful to know now. You have options: refactor the models incrementally, accept some inconsistency in the short term and address it over time, or take a hybrid approach where some models conform and others don’t. But you discover this before the integration project starts, which means you’re not discovering it in the middle of testing.
3. Do you have a clear set of use cases to deploy against?
This is the purpose question. Connect is an integration platform. It connects your Sparx EA repository to Power BI, Copilot, or other tools. But it doesn’t inherently do anything useful. Usefulness comes from having a concrete question that the integration answers, a stakeholder who cares about that answer, and a decision that gets made based on it.
We’ve watched teams build beautiful integrations that nobody uses. They connected their repository to Power BI with all the right metrics, all the right drill-down dimensions, all the right filtering options. Then nobody opened the reports. Why? Because nobody had asked the team to answer a specific question. The reports existed in a vacuum. They were technically impressive and operationally worthless.
A use case looks like this: the CTO wants to know the cloud adoption rate across the business. She needs to know how many applications are on cloud infrastructure versus on-premises versus hybrid. She needs to see this broken down by business unit and by application age. She needs monthly updates to track progress toward the cloud migration strategy. That’s a use case. That’s something worth building an integration to answer.
What this means if the answer is no: your Connect project delivers a solution to a problem nobody’s trying to solve. You’ll complete it on time and on budget. You’ll have a beautiful integration. It will sit unused because the stakeholder who might care about it doesn’t know it exists, or doesn’t know how to interpret the output, or discovered that the output doesn’t actually answer what they thought they wanted to know.
What to do about it: define your use cases before you start. Not perfectly—use cases will evolve—but concretely. Work with the business stakeholders who are going to use the integration. Ask them: what question are you trying to answer? What data do you need to see? How frequently? Who else needs to see it? What decision gets made based on this information? Document the answers. Bring those use cases to the Connect engagement. The integration team will use them to design the right data model, the right reports, the right automation. More importantly, the business stakeholders will know what’s coming, and they’ll be ready to use it when it arrives.
4. Do you have a named business owner for the initiative?
This is the accountability question. Connect projects that succeed have a business stakeholder who is pulling for the output. Not an EA team member hoping to deliver something useful. A business stakeholder—a department head, a program director, someone with budget authority and decision-making power—who has explicitly committed to owning the initiative.
This person doesn’t need to be technical. They need to care about the output. They need to have standing in the organization to make sure the output gets used. They need to show up. They need to champion the integration internally so that when it’s ready, the people who should use it actually do.
We’ve run projects without a named business owner. The EA team owns it. The EA team drives the requirements. The EA team uses the output. And then the CTO asks the team what they’ve been working on for the last three months, and the team can’t explain why it matters. That integration likely still exists somewhere. Nobody’s using it.
What this means if the answer is no: your project becomes an EA initiative rather than a business initiative. It might still deliver something. It probably won’t be adopted. Or adoption will be limited to the EA team itself, which means you’ve built a tool that helps architects, not a tool that helps the business.
What to do about it: find a business owner now. Before the project starts. Have a conversation with the department or function that would benefit most from this integration. Is it the technology strategy office? Is it the infrastructure team? Is it finance? Is it operations? Whoever it is, get someone from that area to commit to owning the initiative. Get it on their calendar. Get it in their budget. Get them involved in defining the use cases. They don’t need to be the one who implements the integration. They need to be the one who cares about whether it succeeds.
5. Do you know your target AI tool ecosystem?
This is the technical strategy question. Connect can integrate Sparx EA with Power BI, with Copilot, with other AI tools. But each of those ecosystems has slightly different requirements, slightly different data shapes, slightly different integration patterns. A Microsoft-first organization will build the integration differently than a Salesforce-first organization, which will build differently than one that’s using multiple tools in parallel.
This isn’t a blocking issue. The integration platform is flexible enough to support different ecosystems. But it’s not a zero-difference decision. If you choose wrong—if you optimize for Microsoft integration and then realize six months later that your AI platform strategy is actually Salesforce-first—you’re going to do some rework.
What this means if the answer is no: you start the project without a clear sense of the technical direction. You might build in one direction, then discover that the business is moving in a different direction. Or you build something that works but that requires rearchitecture if your tool strategy changes. It’s not catastrophic, but it’s waste.
What to do about it: decide on your AI tool ecosystem now. Get the CTO and the technology strategy team in a room. Ask: Microsoft-first or Salesforce-first or mixed? Is Copilot going to be the primary AI interface for executives and analysts, or is Power BI? Are we building this for internal use or for customer delivery? Does the integration need to support multi-tenant scenarios? These decisions determine the technical direction of the project. Figure them out upfront.
Ready to start?
If you can answer yes to four out of five of these questions, you’re ready for Connect. The infrastructure is in place. The governance is defined. The use cases are clear. The business is committed. The technical strategy is set. That’s the environment where Connect projects succeed.
If you can answer yes to fewer than three, Discover is the right starting point. Discover is built to help you answer these five questions. It takes four to eight weeks. It results in a roadmap that tells you what to do next: which infrastructure work to prioritize, whether you need MDG profile work, what your use cases actually are, who should own the initiative, and what your technical strategy should be. That roadmap then informs a Connect engagement that’s much more likely to succeed because the foundation is in place.
The teams that struggle are usually the ones trying to skip the foundation work and jump straight to building. The five questions are there to help you recognize which situation you’re in. Answer them honestly. If you’re ready, start Connect. If you’re not, invest the time in Discover. It takes less time upfront, and it saves months of rework on the back end.
