## 4 The Blueprint Concept
### Types of Blueprints  
A blueprint can be classified based on its status. If a blueprint has already been submitted to a marketplace repository, such as the one provided by SAP [25], and thus can be purchased and reused by other application developers, it is called a _Source Blueprint_. In contrast, a blueprint under development is called a _Target Blueprint_. Application developers can use the blueprint template to describe their offerings in a target blueprint that may reuse other source blueprints and finally be deployed on a cloud infrastructure. For instance in the scenario in Section 2, TaxiTilburg may describe their _TaxiOrdering-SBA_ offering in a target blueprint called _TaxiTilburg-Blueprint_ and AutoInc may describe its _TaxiMgt-SaaS_ offering through the _AutoInc-Blueprint_ target blueprint. Other blueprints in the scenario are classified as source blueprints that are available in a marketplace repository and can be selected and reused by the application developers of TaxiTilburg or AutoInc.  
A cloud service offering is incomplete if there are still resource requirements on which it relies. To complete this offering, one has to retrieve further offerings of other source blueprints from the marketplace repository to fulfill the resource requirements. Hence, we can also distinguish the two following types of blueprints depending on the completeness of their offerings:  
* _Resolved blueprints_: A blueprint is resolved if all of its offerings are complete and ready to be deployed and consumed. For instance in our scenario in Section 2, the blueprints used to describe _SMS-Delivery-SaaS_, _CaaS-PaaS_, _PostgreQL-PaaS_, _Jonas-PaaS_, _and Ethernet3 Gbit-IaaS_ offerings fall under this category. According to our assumption, they contain only complete offerings.
* _Unresolved blueprints_: At least one of the offerings captured in this type of blueprint is incomplete, _i.e._, it is not yet ready to be consumed and still relies on the underlying resources for the deployment. Examples of this type of blueprint are the ones capturing the _TaxiOrdering-SBA_, _TaxiMgt-SaaS_, _and Orchestra-PaaS_ offerings in the case study. In this case, the service provider needs to specify in the blueprint the resource requirements. He relies on the application developer who is responsible for the \"blueprint resolution\". This task includes searching for  
Figure 3: Fundamental Blueprint Structure.  
available blueprints in the repository to fulfill the stated resource requirements. Unresolved blueprints are inherently customizable since the consumers will also be given the ability to customize the underlying configurations of the blueprints after they have been resolved.  
A target blueprint is always unresolved, as it requires other source blueprints to fulfill its resource requirements. Source blueprints can be both resolved and unresolved. In case an unresolved source blueprint is retrieved by the application developer from the marketplace for the reuse, it iteratively becomes a new target blueprint that requires the \"blueprint resolution\" task.  
As pointed out in the introduction, our approach is to compartmentalize the monolithic cloud offering in three different layers (SaaS, PaaS, IaaS) and use the blueprints to describe each of these layered resource offerings. The advantage is that blueprints can be flexibly (re-)assembled in different configurations to form a complete SBA. The first step to enable such a flexible syndication of cross-layered blueprints is to support a formal template for describing it in an unambiguous manner. In the next Section 5 we introduce the Blueprint Template as a standard way to describe cross-layered cloud service offerings.