Any tips for modeling discrete technology such as PBX?

Post Reply
Kevin Campbell
Posts: 40
Joined: 13 Sep 2010, 20:26

We are extending our modeling into the domain of more discrete items of deployed technology, such as video conferencing equipment and switchboard/voicemail systems.

I've extended the model for Site to include full address along with Longitude and Latitude, as this makes it easier for us to visualise some of the data through map overlays.

We don't really have architecture patterns for switchboards and the like, but I'd like to represent more than just the existence of a technology node - any suggestions from past experience?

Thanks

Kevin
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi Kevin,

Very interesting to hear what you've been doing. Sarah is about to post a blog about a range of exciting updates to the Meta Model and the Viewer.

One of these meta model updates is to add a section to EA_Support called Geography that enables you to locate Site instances (as you have) either by a region or by specific geocodes. We've been doing some geography-map views, too!

On to your question about the PBX technologies.
We treat all sorts of technology in the same way, whether it's more physical stuff like machinery or whether it's software.
We capture these as Technology Components (e.g. switchboard system, voicemail system and so on) and map these to the Technology Capabilities that they provide. We can then go onto capture the Technology Products that we have, playing the roles of switchboard system, voicemail system etc., via the Technology Product Role class and on these instances we can use the Lifecycle Status to capture our technology strategic view of the use of that Technology Product to provide that particular Technology Component.
A forthcoming update to the meta model allows multiple Lifecycle Status values for a Technology Product Role.

To capture how these things are used, it can often be enough to capture the Product and the Component in the logical view of the Technology Layer and then capture instances of these Technology Products in the Technology Physical as Hardware Instances. We can capture the dependencies between the physical instances to get an understanding of what might happen if we change / remove switchboard X.

I've certainly taken this approach in the past, where we have a good coverage of the physical view (servers, SANs, network devices, etc.) mapped to the relevant Technology Product (so that we know what each physical instance is) but with not much in terms of things like Technology Product Builds. And this is just fine if that meets the current requirement in terms of reporting / views.

Of course, if we do start to define "standard builds" of these sorts of technology - even if they are purely/largely physical things (rather than software) then we can define those using the Technology Product Builds, which make no assumptions about the nature of the Technology being used in terms of hardware/software etc.
And we can also capture these templates / architectures at the Technology Component level, too using the Technology Composite Architectures to define the "classes" of technology that we use, e.g. in a CTI solution, our voice communications platform or the like.

Hope this makes sense. If I've missed the point, do let me know - and look out for Sarah's blog about all the new stuff that is coming very soon!

Jonathan
Essential Project Team
Post Reply