If you are smart enough to think about Enterprise Architecture as you are launching your startup, congratulations! Not only you have taken a solid step that requires a lot of bravery but also you are in the BEST position to model your ideas before you build an entire process with educated guess-estimates. Make no mistake, there will always be unknowns, what you can do is to identify them and try to reduce the number of unknowns as much as possible.

There is no single source of truth describing how the inner systems are connected. In the best-case scenario, there is fragmented knowledge all over the place scattered among business teams, IT Application Development, IT Operations, product teams, etc. In most cases, there are no models/schematics (note here how we don’t use the word documentation) and instead there is Bob or Jane who knows everything there is to know about business scenario A or IT system X. Bob and Jane are already tied up on day-to-day tasks, so they will have to carve time out of their schedules to describe in words a current state. Bob and Jane here play the role of knowledge-hoarders; either on purpose or by accident. This is assuming that Bob or Jane are eager to share what they know (knowledge transfers). It is a fact of life that job insecurity more often than not motivates people to not share or to share on a need to know basis. Yet, even if people are eager to share, they all have their own view which is biased in one way or another and more importantly neither Bob nor Jane may be experts in effective knowledge transfers.

Even if (which is not common), you happen to have engineers creating their own schematics modelling IT Systems with Visio and business folks modelling their business scenarios using BPMN (business process modelling notation), they generally have different understandings of the boundaries of different components. Business folks may be absolutely convinced there is a single stand alone business process that is realized by a single stand alone application component. Reality will tell you, the business process is realized by multiple application components, which in turn are realized by a J2EE container who is already obsolete, but nobody knew! You need a single modelling notation for the sake of architecture coherence.

Since you want to have a single notation for both Business-Product architecture and IT Application-Data architecture so that the entire company speaks the same language, you would be wise to use a single language that provides the elements to describe Business, Product, IT Application (Logic), IT Data (logic)
and Technology.